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Abst  ract 


The  f^ducational  Hata  Rase  vSysten  (RDRS)  is  an  interactive 
'^tta  base  nana,n:enent  system  designed  for  educational  use.  The 
system  implements  both  the  relational  and  hierarchic  v  i  ev.’s 
data.  '^DRS  is  y^ritten  in  and  accessed  -Prom  APL  Pins. 


A  student  user  oriented  description  of  the  fPRS  information 
structures  and  data  manipulation  language  is  presented.  This  is 
follo'.ved  by  a  numbor  of  suggested  exercises  and  games  to  be  used 
v/ith  EDRS  In  a  course. 
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chapter  1 

Int roduct ion 

This  manual  contains  procedures  for  operating  the  Educational 
Data  Pase  System  (EDPS)  , 

EDBS  is  a  data  base  management  system  used  primarily  for  the 
teaching  of  data  base  concepts.  From  a  standard  APL  terminal, 
users  may  access  the  system  to  query  a  data  base  as  to  its 
contents,  or  to  update  information  stored  there. 

Procedures  are  provided  for  retrieving  and  modifying  data  in 
hierarchical  and  relational  data  bases.  The  procedures  are 
accessible  conver sa-^ iona  lly ,  i.e.,  commands  can  be  typed  in 
directly  with  immediate  system  response,  or  may  be  called  from 
user  created  API  functions. 

This  first  chap-'-er  discusses  the  overall  capabilities  of 
EDBS,  explaining  the  access  procedures  and  some  of  the  technical 
terms  used  in  this  manual. 

The  second  and  third  chapters  explain  the  structure  of 
hierarchical  and  relational  da-^a  bases  respectively,  giving  the 
command  syntax,  explaining  the  use  of  the  commands,  and  listing 
the  possible  error  messages  that  may  arise  from  EDBS. 

The  fourth  chap-*:er  contains  all  the  necessary  information 
about  existing  data  bases  loaded  for  class  use.  A  few  exercises 
are  given  to  let  users  familiari-ze  themselves  with  the  data  base 


commands. 
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Chapter  five  explains  -t-wo  games  (suggested  exercisas)  to  be 
usGc?  as  teaching  aids  for  data  base  management  concepts  and  uses. 

Finally,  thf=  las*:  chapter  gives  the  syntax  for  both  the 
hierarchical  and  relational  subsystem  commands  using  3MF  (Backus 
-  Naur  Form)  . 

Since  FDBS  is  embedded  in  the  host  language  A?L  PLUS  and  uses 
its  file  system,  a  working  knowledge  of  APL  is  necessary  in  order 
to  manipulate  information  retrieved  from  the  data  base.  Suggested 
reference  manuals  are: 

Gilman,  L.,  Pose,A.J.  ,  A.PL/360  -  An  Interactive 

Approach,  Wiley  and  Sons,  1U70. 

Pakin,5.,  APL/360:  Reference  Manual,  2nd  Edition, 

Science  Research  Associates,  1972. 

The  commands  available  for  a  hierarchical  data  base  are  valid 
for,  and  can  only  be  used  on,  hierarchical  data  bases;  whereas, 
the  relational  commands  may  be  used  on  both  hierarchical  data 
bases  structured  for  relational  access,  and  relational  data 
bases. 

The  operational  parts  of  the  system  at  this  time  are: 

1)  all  hierarchical  commands  on  hierarchical  data 
bases, 

2)  relational  retrievals  on  hierarchical  data 
bases. 


3)  all 


commands  on 


relational  data 


-3  - 
relat  iona  1 
bases. 

Control  commands,  retrieval  commands  and  raoiifica 
commands  are  all  data  base  commands  which  can  be  used  by  a 
to  signal  his  int<=ntions  to  EDBS, 

Control  Commands 

The  term  ’control  commands'  refers  to,  specifically,  t 
different  types  of  commands: 

1)  open, 

2)  close, 

3)  release. 

A.ssociated  with  each  type  is  one  data  base  command, 
commands,  oddly  enough,  are  OPEN,  CLOSE  and  EELEA.SE  (explains 
chapters  2  and  3)  . 

The  control  commands  for  the  hierarchical  and  rslati 
subsystems  are  identical. 

In  order  to  access  a  data  base,  that  data  base  must  firs 
0£ened  by  issuing  an  open  command.  This  serves  to  initia 
variables  that  the  EDBS  procedures  require,  tie  files  an3  per 
various  other  bookkeeping  tasks.  The  system  also  creates  and 
a  file  to  be  used  as  a  buffer  area  (see  Puffer  A.r3a  in 
chapter) . 

No  data  base  commands  are  accepted  until  a  data  base  has 


tion 

user 


hree 


The 
d  in 

onal 

t  be 
lize 
form 
ties 
this 

beer 


opened 
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Only  on-^  data  bas<^  !Tiay  be  open  at  a  time. 

Tf  a  data  base  has  been  opened,  then  a  c]_ose  control  command 
is  necessary  before  signing  off  or  before  opening  another  data 
base.  The  close  command  unties  the  system  files  and  erases  the 
user*  s  output  buffer  file. 

If  a  data  base  is  not  closed  before  signing  off,  the  user 
will  be  unable  to  use  EDBS  the  next  time  he  signs  on.  This  is  due 
to  the  fact  that  the  output  buffer  file,  required  by  the  system 
and  created  in  the  open  command,  is  not  erased  if  a  close  command 
is  not  issued.  Subsequently,  an  error  will  result  the  next  time 
an  a t tem pt  is  made  to  open  any  data  base ,  since  the  system  will 
try  to  create  a  file  that  already  exists.  If  this  condition 
arises,  inform  a  demonstrator  immediately, 

-  command  is  used  to  remove  the  hold  status  (see 
Modification  Commands  section)  from  a  data  base.  Issuing  a 
release  implies  tha-»-  the  planned  modification  is  being  cancelled. 

Petrieval  Commands 

Retrieval  commands,  as  implied  by  the  name^  are  used  to 
retrieve  information  from  data  bases.  The  commands  differ  for 
hierarchical  and  relational  data  bases;  therefore,  refer  to  the 
chapters  on  hierarchical  and  relational  subsystems  for  the  syntax 
and  explanation  of  these  commands. 

There  are  two  types  of  retrieval  commands  available:  get  and 


get-hold. 


-S  - 

The  g^et  commandF  are  used  only  to  retrieve  infornation  from 
the  data  base  and  place  it  in  the  buffer  area.  It  is  assumed 
that  no  further  action  will  be  required  by  the  system  cancerninq 
the  information  retrieved  in  the  get. 

commands,  like  get  commands,  retrieve  data.  In 
addition,  they  place  the  data  base  in  hold  status  (explained  in 
Modification  Commands  section)  and  retain  sufficient  information 
to  perform  a  modification. 

In  both  the  hit-rar ch ical  and  relational  subsystems,  data 
retrieved  from  the  data  base  may  be  qualified  with  a 
qualification  expression.  By  testing  data  values  with  the 
conditional  operators  <,  <,  =,  >  and  >,  (only  =  and  t  are 
allowed  for  character  string  comparisons)  one  can  pick  out  a 
subset  of  the  data  that  would  normally  be  retrieved.  Tha  logical 
connectors  A.ND  and  OP  can  be  used  to  combine  various  conditional 
tests  to  further  qualify  the  data,  making  the  retrieved  subset 
even  smaller. 

Using  this  method  of  qualifying  data,  it  is  possible  to 
retrieve  only  a  single  logical  unit  of  data. 

Modification  Commands 

Different  types  of  modifications  that  may  be  made  to  a  data 
base  are  updates  (bringing  old  information  up  to  date),  deletions 
(getting  rid  of  unnecessary  data)  and  insertions  (incorporating 


new  data) 
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For  each  data  base  in  FDBS,  there  is  only  one  physical  copy 
of  the  data.  Thus,  one  physical  copy  of  the  data  base  must  be 
shared  among  all  users.  For  retrievals  alone,  this  presents  no 
problems.  However,  when  modification  of  the  data  base  is  allowed, 
some  form  pf  lock  on  the  data  base  must  be  introduced.  A  lock 
during  modifications  ensures  data  integrity  by  allowing  only  one 
user  at  a  time  to  modify  data  and  thus  ensure  that  siraultaneous 
modifications  of  the  same  data  do  not  occur.  In  FDBS  this  lock  is 
performed  in  two  stages  as  explained  below. 


Some  modification  commands  must  be  preceded  by  a  get-hold 
command  which  finds  the  data  values  in  the  data  base  that  are  to 


if ied . 

Issuing  a  qe 

t-hold  comma 

nd  places 

the  data  base  in  a 

ta tus. 

This  has  th 

e  following 

effect : 

get 

commands  by 

other  users 

are  still 

possible. 

any 

subsequen  t 

get-ho Ids 

issued  by 

other  users  on  the 

same  data  base  are  placed  in  a  wait  state  until  the 
current  hold  on  the  data  base  is  removed. 


When  the  actual  modification  command  is  issued,  the  data  base 
is  temporarily  types  of  access  until  the 
modification  is  completed.  When  the  modification  command- 
completes,  both  ^he  lock  and  the  hold  are  removed  from  the  data 
base.  Only  at  this  time  car  one  of  the  pending  gat-hold  commands 
(if  any)  proceed.  Tf  more  than  one  user  is  waiting,  the  problem 
of  predicting  who  will  proceed  is  indeterminate,  since  users 
awaiting  execution  of  get-hold  commands  do  not  form  a  queue,  but 
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sit  in  a  delayed  wait;  therefore,  whichever  process  gets  control 
of  the  CPU  first  will  oroceed. 


It  should  he  stressed  that  a  hold  on  a  data  base  is  not 
applied  until  any  previous  hold  on  that  data  base  is  removed,  and 
that  the  data  base  is  locked  only  when  there  are  no  retrievals 
active  in  that  data  base.  For  these  two  reasons,  it  should  be 
obvious  that  during  high  modification  and  retrieval  activity,  a 
modification  command  may  take  a  long  time  to  execute  and  a  get- 
hold  command  even  longer.  Therefore,  a  user  should  not  be 
surprised  if  a  substantial  length  of  time  passes  for  a  get-hold 
or  modification  command  to  complete  (especially  at  paak  usage 
hours  -  usually  early  and  late  afternoons) . 


The  amount  of  t 
determined  to  a  large 
base  and  by  how  long  e 
the  desired  modificati 


ime  spent  waiting  to  exec 
extent  on  the  number  of  use 
ach  user  "fiddles”  around  b 
on.  Therefore, 


ute  a  CO 
rs  of  th 
efore  co 


mmand  is 
at  data 
mplet ing 


PLEASF.  DO  NOT  TIE  UP  THE  SYSTSH. 

Know  beforehand  what  changes  are  to  be  made 
quickly,  keeping  the  time  between  the  get-hold 
modification  command  as  short  as  possible. 


and  then 

make 

them 

command 

and 

th  9 

A.  word  of  warning  is  necessary.  No 
completely  foolproof.  Due  to  the  interactive 
problem  is  even  more  acute.  Therefore,  users 
these  simple  rules: 


locking  mechanism  is 
nature  of  EDBS,  the 
should  try  to  fellow 
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1)  follow  a  get-hold  command  by  a  modification 
command  or  release  command  in  as  short  a  time  as 
possible . 

2)  Never  interrupt  a  get-hold  or  modification  command  by 
striking  the  ATTN  key.  Pemember,  the  system  performs 
on-line  modifications.  They  may  take  time,  perhaps  as 
long  as  a  few  minutes. 

DO  NOT  GET  IMPATIENT. 


If  a  get-hold  or  modification  command  is  interrupted, 
always  resume  execution  of  the  suspended  function  at  the 
line  number  at  which  the  interruption  occurred  (by  a  --> 
line  number).  Otherwise,  a  user  may  permanently  lock 
himself  and  other  users  from  further  access  to  the  data 
base . 


3)  If  the  APL  system  happens  to  go  down  while  EDBS  is 
executing  a  get-hold  or  modification  commmanl  or  the 
telephone  line  should  drop,  a  user  will  not  be  able  to 
access  the  data  base  he  had  open  when  he  signs  back  on. 
In  addition,  he  will  probably  have  locked  the  data  base 
to  further  access  by  other  users.  Bring  any  such 
situation  to  the  attention  of  a  demonstrator 
IMMEDIATELY.  He  will  be  able  to  correct  the  situation. 
Afterward,  the  data  base  should  be  checked,  as  the 
modification  will  probably  not  have  occurred. 


N^ver  sign  off  while  a  data  base  is  in  hold  status.  By 
doing  this,  other  users  will  be  prevented  from  modifying 
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the  data 

base.  The  culprit  who 

does 

this 

can 

identified 

other  users 

and  will  have  to  endure 

• 

the 

wrath 

of 

Accessing  EDBS 

The  followirg  procedures  should  be  followed  in  orde 
access  EDBS: 

1)  Sign  on  as  required  by  API. 

2)  Load  the  version  of  ^DPS  required  by  typing 


) LOAD  <1 

ibra 

ry 

number>  < 

workspace 

nam 

e> 

Decide 

whic 

h 

exist ing 

data 

base 

you 

wish 

to  wo 

rk  f 

making  s 

ure 

it 

is  compat 

ible 

with 

the 

ver 

sion 

of 

you  hav 

e  lo 

aded,  and  op 

en  that  data 

base 

using 

the 

command 

a  s  e 

xplained  in 

chapters  2 

or 

3. 

4)  You  are  now  in  a  position  to  access  the  data  base  u 
all  of  the  commands  available  in  the  version  of  EDBS 
have  loaded,  as  well  as  having  full  APL  capabilit 
File  operations  provided  are  in  the  form  of 
primitive  fil^  function  FF  as  described  in  the  APL 
File  Subsystem  Instruction  Manual.  There  are 
additional  restrictions  on  file  management: 

i)  The  file  tie  numbers  of  any  user  file  mus 
greater  than  10,  the  first  ten  file  tie  num 
being  reserved  by  the  system. 


be 

the 


r  to 


rom , 
EDBS 
open 

si  ng 
you 
ies. 

the 

PLUS 

two 

t  be 
bers 


ii)  A  maximum  of  4  user  ^iles  may  be  tied  at  a  time. 
Only  -^en  file  ties  are  allowed  at  any  given  tiie  by 
APT.  PLUS;  EPBS  ties  six  files  for  its  own  use, 

5)  DO  NOT  FOPCF*^,  after  completing  all  desired  operations, 
the  data  base  must  be  closed  with  the  close  command. 
The  syntax  for  close  is  explained  in  both  the 
hierarchical  and  relational  subsystem  chapters. 

6)  Sign  off  as  required  by  APL. 

Buffer  Area 

The  term  ’buffer  area’  in  this  manual  refers  to  the  system 


created  file 

which 

acts  as  an 

interface  for 

the 

transf 

erring 

of 

data  between 

SEES 

and  APL 

(the  user) . 

All 

retri 

e  vals 

and 

modi f ications 

occur 

between  the  EDBS  data 

base 

and 

the 

EDBS 

buffer  area. 

The  user  issues  a  data  base  retrieval  command,  which  on 
successful  completion  automatically  overwrites  the  buffer  area 
with  the  retrieved  data.  If  the  command  fails,  the  buffer  area  is 
cleared. 

Similarly,  update  data  must  first  be  placed  in  the  buffer, 
then  transferred  to  the  data  base.  The  buffer  area  is  cleared 
only  if  a  modification  command  succeeds. 

Data  in  this  buffer  area  can  be  accessed  with  the  READ  and 


WRITE  ut ility_com mands  as  explained  in  chapters  2  and  3. 
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Control  of  Execution 


There  is  a 

sys 

tested  after  any 

EDBS 

executed  in  a  program 

ern  defined  variable 
command  to  control  th 


STATUS, 

whioh  can  be 

order  of 

statements 

The  value  of  STATUS  is  0  when  a  control,  retrieval, 
modification  or  utility  command  has  completed  successfully, 

A  value  of  1  for  STATUS  means  that  a  syntax  error  was 
detected  in  the  issued  command,  and  an  error  message  is  printed 
out  to  that  effect. 

For  the-  hierarchical  subsystem,  STATUS  may  have  additional 
values  indicating  various  conditions.  Refer  to  chapter  2, 
Retrieval  Commands  section,  for  further  clarification, 

'^he  PFAP  and  WRITE  buffer  commands  set  the  variable  STATUS. 
Therefore,  to  check  for  the  success  or  failure  of  a  control, 
retrieval  or  modification  command,  STATUS  should  be  tested 
immediately  after  a  command  is  issued  and  before  any  other 
command  is  issued. 


Error  Messages 


There 


are  two 

1) 


sources  of  error  messages 

the  host  language  APL, 
EDPS  . 


in 


this  system: 


2) 
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?vPL  error 
while  executing 
become  familiar 


messages  arise  while  managing  data  in  a  file,  or 
a  seguence  of  APL  instructions.  You  should  have 
with  these  while  learning  APL, 


EDBS  error  messages  arise  when  issuing  ED3S  control, 
retrieval,  modification  and  utility  commands.  The  error  messages 
are  characterized  by  the  leading  characters: 

ERROR  : 


Even  though  they  are  self  explanatory,  a  list  and  explanation 
of  the  error  messages  can  be  found  in  the  hierarchical  and 
relational  chapters. 


If  an  EDBS  command  is  issued  which  results  in  an  APL  error 
message,  this  is  an  indication  that  the  system  has  not  been  fully 
debugged.  Please  keep  a  list  of  all  such  occurrences  and  give  it 
to  a  demonstrator,  who  will  see  what  can  be  done  to  fix  the  bugs. 


Workspace  Size  Restrictions 


Due  to  a 
allocated  by 
messages  may 
or  retrieving 


severe  limit 
APL  on  the  3 
arise  while 
a  great  dea 


ation  on  the  current 
60  system  at  TJ,  of  T, 
performing  somewhat 
1  of  information. 


size  of 
,  work 
complex 


work  spaces 
space  full 
ret  rievals. 


There  is  not  much 

that  can 

be 

done  about 

this,  th 

following  steps  might  be 

tried: 

1)  Check  to  see  if 

there  are 

any 

suspended 

function 

up  space  in  the 

workspace. 

If 

there  are. 

follow 

ough  the 


s  taking 
step  2 


until  all  suspended  functions  are  remov'^l 


T  :>  1  C' t  e  r  m  i  n  e 


if  are  any  susp<=nded  fa  net  ions,  ent^r 

) 

7.  null  return  indicates  no  suspended  functions. 

7)  a  k  c  t  h  f-  a  s  s  i  g  r  p  n  t 

S"7iTrj.S  <-  1 

followed  hv  a  branch  to  2e>ro 

->  0 

If'  any  furthest  -rror  messages  arise,  ignore  tliem 
branch  o  Z‘=ro  again  until  all  suspended  functions 
removed,  this  happens  in  a  get -ho  Id  command, 

also  issu“  a  release  command, 

3)  Use  less  complex  qualification  expressions  if  you 
get-^ing  workspace  full  messages. 

Pot  at  j_on 

The  following  no*:ation  is  used  throughout  this  manuax.  PI 
become  familiar  with  i-^. 

(  }  denotes  that  the  quantity  within  brackets 

opt iona 1 . 

<  >  quantities  in  lower  case  within  angle  brackets  are 

i.  e 


and 

are 

then 

keen 


ease 


non¬ 


terminal  symbols. 


•  r 


should  be  replaced  by  a  data 
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base  name,  segment  name,  relation  name,  field 
domain  name,  date,  number  or  string,  depending  on 
is  within  the  brackets. 


name, 

what 
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Chapter  2 

Hierarchical  Subs Ystem 

A  hierarchical  data  base  is  an  example  of  a  tree  logical  data 
structure.  In  order  to  help  describe  the  tree  structures 
associated  with  hierarchies,  consider  the  organization  of  a  large 
company. 


r 

”1 

j  PRESIDENT 

1 

1 

1 

1 

1  NAME 

1 

ADDRESS 

1 

1 _ 

~i — 

1 

1 

r 

j 

“1 

1  VICE 

-PRESIDENT 

1 

1 

1 

1 

1  NAME 

1 

ADDRESS 

1 

L - , - 

- J - 

1 

1 

1 

1 

1 

1 

1 

1 

DIRECTORS  i 

1  MANAGERS 

!  1 

1 

1 

NAME  1  ADDRESS  | 

J 

1  NAME 

L 

1  ADDRESS 

I 

I - * - 1 

I  EMPLOYEES  j 

]  ]  I  I 

1  NUMEEE  j  NAME  \  SALARY  | 


level  1 


level  2 


level  3 


level  4 


Eig.  2.1  Definition  Tree  for  a  hypothetical  company. 


One  of  the  first  things  that  must  be  done  is  to  set  up  the 
organizational  hierarchy  of  the  different  levels  of  management 
required,  even  before  there  are  any  personnel  to  fill  the 
positions.  Let  this  organizational  hierarchy  be  represented  by  a 
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def init ion_tree.  Diagraraatically,  it  would  appear  as  in  figure 

2.  1. 

The  lines  joining  nodes  in  figure  2.1  mean  that  the  son  nodes 
"are  responsible  to”  parent  nodes. 

The  definition  tree  conveys  only  general  information.  Figure 
2.1  does  not  specify  how  many  Presidents  there  are,  or  how  many 
Vice-presidents  each  President  has,  or  that  all  Presidents  have 
the  same  number  of  Vice-presidents,  etc.  The  same  applies  foe  the 
number  of  Directors,  Managers  and  Employees. 

Each  node  of  a  definition  tree  represents  a  §§lien t_t X2.e  in  a 
data  base.  For  a  giver  data  base,  each  segment  type  must  have  a 
unique  segment,  name  (e.g..  President,  Vice-president,  Directors, 
Managers  and  Employees  are  unique  segment  names).  The  segment 
types  have  no  da'*-.a  values  associated  with  them  (i.e.,  from  figure 
2.1  it  is  no"^  known  who  the  President  or  Vice-president  is, 
etc.)  but  the  positioning  of  the  nodes  within  the  hierarchy 
determine  the  parent  -  son  relationships  between  the  different 
segment  types. 

Each  segment  ‘•■ype  resides  at  a  hierarchical  level  in  the 
tree;  the  level  being  an  indication  of  the  distance  from  the  root 
of  the  tree. 

The  highest  level  node  (i.e.,  level  1)  is  referred  to  as  the 
root_seqment_type ,  while  the  nodes  at  levels  2,  3,  etc.  are 
called  dependen t_seqm en t _ty£es . 
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Having  decided  to  keep  some  information  about  the  executives 
of  this  company,  the  type  of  data  desired  can  also  be  stored  in 
the  definition  tree.  For  Presidents,  vice-presidents.  Directors 
and  Managers  a  name  and  an  address  will  be  stored,  for  Employees 
a  man  number,  a  name  and  a  salary.  Names,  addresses,  etc.  are 
associated  with  the  personnel.  Still  as  yet  though, 
there  are  no  attribute  values  to  be  stored, 

attributes  of  the  different  segment  types  are  referred  to  as 
fields  of  the  segment  types.  These  fields  are  given  iLiil^names 
which  must  be  unique  within  a  given  segment  type.  In  figure  2.1, 
Name,  Address,  Number  and  Salary  are  field  names. 

Assume  now  that  enough  people  have  been  hired  to  fill  any 
required  positions  and  that  all  relevant  information  about  each 
has  been  collected. 

At  this  stage  the  occurrences  tree  can  be  introduced.  It 
contains  all  information  required  about  the  executives.  Each  node 
of  this  tree  is  an  occurrence  of  data  values  in  the  data  base. 

Each  segment  type  has  many  distinct  occurrences,  (In  figure 
2.2  there  are  3  occurrences  of  the  President  segment  type.)  Each 
occurrence  is  a  se^nient  in  the  data  base  and  contains  the 


information  that  the  fields  of  the  segment  type  specify 
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Fig.  2.2  Occurrences 
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1  1  imaginary  head  noie 

i  I 
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1  I  I 
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PRESIDENT 
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PRESIDENT 

1 

r" 
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1 

JOHN  1  MONTREAL 

1 
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PAUL  1  VANCOUVER 
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VICE-PRESIDENT 
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VICE-PRESIDENT 
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1  1 

JIM  )  OTTAWA 

- r 
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.  J 
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LEILA  1  PICTON  1 
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etc. 

Tree  for  a  hypothetical  company. 


The  name  above  each  node  tells  what  segment  type  tha  node  is. 


The  following  are  President  segments  from  figure  2.2: 


ANNE,  TORONTO 
JOHN,  MONTREAL 
PAUL,  VAiNCODVER 


where  ANNE, 
MONTREAL  and 


JOHN,  and  PAUL  are  Name  field  values,  and  TORONTO, 
VANCOUVER  are  Address  field  values. 


In  order  to  construct  the  occurrences  tree  for  a  data  base  as 
EDBS  sees  it,  follow  these  steps: 


i) 

Let 

the 

imagin 

ary  ro 

0 1  of 

the 

tree  be  the 

data 

base 

name 

,  its 

sole 

purpose 

being 

to 

logically 

join 

all 

i  nst 

ances 

of  dat 

a  base 

records. 
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ii)  Branches  of  a  nod<a  roust,  bp  generated  from  left  to  right. 
Peferrir.g  "^o  the  data  definition  of  the  lata  base 
(explained  in  chapter  (i)  ,  generate  as  roany  branches  from 
each  node  as  there  are  sons  of  one  type  allowel. 
Generate  branches  for  sons  of  different  types  i.i  the 
order  as  they  sequentially  appear  in  the  data 

definition.  Not  all  nodes  will  contain  information, 
these  may  be  erased  or  roay  not  be  added  in  the  first 
place. 

The  term  ’traversal'  in  the  hierarchical  subsystem  will  imply 
a  preorder  traversal  of  the  occurrences  tree. 

A  preorder  tree  traversal  is  given  by  the  recursive 
instructions: 

i)  visit  node  if  it  has  not  already  been  visited,  or  if  it 
has  not  been  disqualified  (see  below) , 

ii)  traverse  the  leftmost  son  not  previously  traversed, 

iii)  if  no  sons  are  left  to  be  traversed,  go  back  to  parent 
node, 

node  is  disqualified  from  being  visited  in  the  preorder 
traversal  if  it  does  not  meet  +-he  required  specifications  as  set 
down  by  the  user  in  the  syntax  expression  <quaii f ica t ion 
expression^,  or  is  not  of  the  correct  type.  For  instance,  to 
retrieve  all  Employee  segments  of  tlie  hypothetical  company  with 
man  numbers  larger  than  1000C,  Employee  segments  with  man  numbers 
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less  than  or  <=01^1  to  10CCC  would  bf-  disqualified  from  being 
visited  alona  with  all  non- Em  pi oyee  segments. 

The  next  node  in  a  tree  is  determined  by  a  preorder  traversal 
of  the  occurrences  tree,  the  starting  position  being  given  by  the 
current  value  of  the  data  base  position  pointer  (explained  later 
in  this  chapter) .  All  nodes  that  come  "before”  the  position 
pointer  are  disqualified,  as  next  implies  a  forward  search. 

A.  preorder  traversal  of  the  tree  in  figure  2.3  would  yield 
segments  in  the  following  order: 


(ANNE,  -^OPONTO) 


PRESIDENT  segment 


(PHIL,  WHITBY) 


VICE-PRESIDENT  segment 


(LOH,  POME) 


DIRECTOR  segment 


(SUE,  U  of  T) 


DIRECTOR  segment 


(JOHN,  LISBON) 


MANAGER  segment 


(92314,  JACK,  85) 


EMPLOYEE  segment 


(Q52V,  EPED,  laC) 


EMPLOYEE  segment 
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I _ j 


■^ig.  2.3  A  single  record  from  the  data  base  of  a 

hypo theti cal  company. 


An  occurrence  of  a  root  segment  type  is  called  a  IODt_segment 
and  an  occurrence  of  a  dependent  segment  type  is  a 
d epen den t_ segmen t . 


A  data _ base _ record  consists  of  a  single  root  sejmant  along 

with  all  of  its  dependents  in  the  occurrences  tree.  Thus,  a  data 
base  record  is  associated  with  every  instance  of  a  root  segment, 
and  a  data  base  is  comprised  of  data  base  records.  ’^ram  figure 
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2.2,  one  can  see  that  the  data  base  for  our  hypothetical  company 
is  comprised  of  3  data  base  records. 

An  implementation  restriction  of  ED3S  requires  that  fields, 
and  subsequently  segments,  be  of  fixed  si^e.  There  is  also  a 
limit  on  the  number  of  instances  of  a  particular  son  type  (e.g., 
each  President  may  have  a  maximum  of  3  Vice-presidents,  and  each 
manager  may  have  no  more  than  10  Employees,  etc.) 

Each  root  segment  typ<^f  and  hence  each  root  segment,  must 
have  at  least  one  lioy_field  to  be  used  to  uniquely  identify  a 
single  logical  data  base  record  within  the  data  base.  In  our 
company,  this  would  mean  that  all  Presidents  must  have  either 
unique  names,  unique  addresses  or  the  combination  of  the  two  must 
be  unique. 

Non- root  segments  must  contain  a  sequence  field  which  is  used 
for  s<^quencinq  or  ordering  segments  of  the  same  type.  Under  a 
given  paren-^  seqment  ,  all  values  of  a  sequence  field  must  he 
distinct,  ror  Employees,  the  Number  field  should  be  enough  to 
distinguish  between  di^^erent  people. 

Ml  key  fields  and  sequence  fields  are  kept  as  inyer  ted_l  ists 
to  aid  in  the  searching  of  a  data  base.  An  inverted  list  for  a 
field  consists  of  all  ■'■he  different  data  values  in  that  field 
along  with  pointers  into  the  data  base  where  they  occur. 

An  illdexed_f ield  is  any  field  (not  a  key  or  sequence  field) 
for  which  an  inverted  list  Is  maintained. 
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There  is  a  data  base  position  pointer  which  is  automatic 
set  by  the  system.  It  is  updated  after  every  retrieval  comman 
point  at  the  retrieved  segment,  but  is  not  changed 
modification  commands.  If  a  retrieval  command  fails, 
position  pointer  remains  unchanged. 

There  is  a  separate  point 61:7 to- parent  which  is  used  by 
GET  (HOLD)  NEXT  WITHIH  PASFNT  retrieval  commands.  Tt  is  set 
both  the  GET  NEXT  and  GET  UNIQUE  commands  and  the  corraspon 
get-hold  commands  (explained  later  in  this  chapter)  to  the  v 
of  the  data  base  position  ponter.  The  pointer-t o- pa  ran t  rei 
unaltered  after  issuing  the  GET  (HOLD)  NEXT  WITHIN  PA 
commands,  or  if  a  GET  NEXT  or  GET  UNQTUE  command  fails. 


A  short 
the  data  bas 
clarify  dat 
listed  in  ch 

Wherever 
date  or  a  st 
these  data  t 


exnlanation  of  the  symbols  used  in  the  explanatio 
e  commands  is  given  here.  Examples  used  to 
a  base  commands  are  given  for  the  example  data  b 
apter  4. 


1  ue> 

appears. 

replace 

it  with  a 

r^'al  numbe 

See 

chapter  4 

for  the 

correct 

formatting 

ypes. 


Replace  ll^t a_has e_name>  with  any  valid  E^rs  variable  u 
1C  characters  in  length.  Make  sure  that  it  is  the  name  of 
existing  data  base. 

Replace  l2egment _nam e>  with  any  valid  EDES  variable  up  t 
characters  in  length.  Re  sure  that  it  is  a  valid  segment  name 
the  currently  open  data  base. 


ally 
d  to 
by 
the 

the 

by 

ding 

alue 

ains 

RENT 

n  of 
help 
ases 

r,  a 
of 

p  to 
an 

o  2C 
of 
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Replace  <ii£l<l_D.a me>  with  a  valid  ETBS  variable  up  to  20 
characters  long.  The  field  name  must  be  the  name  of  a  valid  fieli 
of  the  segment  being  specified. 

Ml  names  mus-*-  contain  only  letters  or  numbers  and  lust  begin 
with  a  letter.  Underscored  letters  are  not  allowed. 

Replace  £co nd i^ional_ODera tor>  with  one  of  the  following 
mathematical  r^^lations:  <,  <,  =,  *,>,>, 

\  <gua  li  f  ica  tior  _ex_pression>  consists  of  one  or  more 

occurrences  of  the  formal" 

(  <field  name>  <conditional  operator>  <value>  ) 

where  ANT  or  OF  connect  more  than  one  such  occurrence.  Unless 
parentheses  are  used  in  the  qualification  expression  to  change 
the  orde  r  of  e  val ua  ti or ,  AND ' s  will  be  evaluated  before  (take 
precedence  over)  Op’s. 


Control  Commands 


i)  OP^N 

The  formac-  of  the  open  control  command  is: 

'fdata  base  nam6>’ 


f.g.,  in  order  to  open  the  da*- a  base  COMPANY  described  in 
chapter  4,  type  in: 


OPEN  ’COMPANY’ 
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ii)  CirS5 

’"ho  close  control  command  is: 

CLOSE  '<data  base  name>’ 

Be  sure  that  <data  base  name>  is  the  same  data  base  name  ns^d 
in  the  corresponding  open  command, 

E.g,,  to  close  the  data  base  C0?1PANY,  type  in: 

CLOSE  ’COMPANY’ 


iii)  PELEASE 

The  release  command  appears  without  any  arguments,  since  its 
purpose  is  to  unlock  the  data  base.  Just  type  in: 

RELEASE 

E.q.,  if  an  employer  wanted  to  raise  the  salary  of  an 
employee,  he  would  first  have  to  find  the  relevant  segment  in 
the  data  base  with  a  get-hold  command.  But  then  if  he  were 
suddenly  to  decide  not  to  give  the  raise,  ha  would  meralv 
have  to  type 

RELEASE 

to  cancel  the  pay  increase, 

Petr  leva l  _Co mm and s 

All  hierarchical  retrieval  commands  retrieve  only  ona  segmen'*' 
at  a  ’■ime  and  nlace  the  retrieved  segmef^  in  the  buffer  irea.  The 
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segments  C3n  then  be  read  or  modifi-^'d  using  th?  READ  iiid  w’RTT'^ 
commands  explained  in  this  chapter. 

Tf  more  than  one  segment  satisfies  the  condition  SDSoified  in 
<qua  lif  ication  ex  pressior.  >  ,  then  •’■he  first  qualifying  segment 
found  in  the  preorder  traversal  is  retrieved.  ’=’or  lET  IINIQ'J" 
(GU)  and  GET  HOLD  UNIQUE  (GHU) ,  the  starting  position  is  the 
beginning  of  the  occurrences  tree,  for  others  it  is  the  current 
value  of  the  position  pointer.  If  no  segments  maet  th= 
requirements,  STATUS  takes  on  the  appropriate  valua,  and  the 
buffer  area  is  cleared. 

Certain  conditions  arise  during  retrievals  whioti  are  not 
necessarily  errors,  but  are  situations  of  which  the  user  may  want 
to  be  informed.  In  such  cases,  no  error  message  is  printed  out. 
The  variable  STA’^US  takes  on  one  of  the  following  values  to 
indicate  th'=  condition: 

status 

0  Command  successful. 

1  Syntax  error  d'^tected,  error  message  printed. 

2  Hierarchic  h'oundary  crossed.  The  segment  retrieved  lies 
in  a  ditferent  data  base  record  fiom  the  previously 
r<=rrieved  seament.  (GT’  and  GHU  never  set  STATUS  to  2.) 

3  No  segm<=>nt  qualifies,  i.e.,  no  s^^gments  meet  the 
conditions  of  •"he  qualification  expression. 


4 


No  more  segmen'"s 


within  parent 


5  Fn-^  of  da*:a.  baso.  In  GN  •'  processini,  no  more  nodas 

remain  to  be  visited.  In  GN  ’<segment  name^'  orocessinaf 
all  <S(' ament  narae'>  nodes  have  been  visited. 

Condition  G  will  not  arise  in  GFT  NFXT  WITHIN  pa.renI  (GNP)  or 
GFT  HOLD  NEXT  WITHIN  PARENT  (GHNP)  processing.  The  end  is 
detected  by  testing  for  condition  U, 

^very  retrieval  command  updates  the  data  .  base  position 
pointer  to  point  at  -^.he  qualifying  segment  retrieved. 

■"her'^  are  in  all  six  different  retrieval  commands  -  three  get 
commands  and  three  corresponding  get-hold  commands. 

Issuing  a  get  or  get-hold  command  on  a  data  base  already 
placed  in  hold  by  th^  user  is  an  error  and  resul+ s  in  th<^  hold 
being  cancelled. 

i)  G^^T  DNIQIP^ 

The  syntax  "^or  the  GE'^  UNIQUE  retrieval  command  is: 

GU  '^root  segment  na me> ; <guali f ication  expression>‘ 

wher?^  <root  s<=gment  nam,e>  is  the  name  of  a  valid  root  segment 
in  the  currently  open  da-^a  base.  The  GST  UNIQUE  command 
re-^rievss  a  specific  occurrence  of  the  root  segmen"^  <root 
segment  ndme>  with  qualification  <gualif ication  expr^^ssionP 
from  the  data  bas^^  and  places  i'*',  in  the  buffer  area. 

If  the  entire  V^y  of  the  segment  is  specified,  the  segment  is 
guaranteed  to  be  unique,  i.e.,  only  one  seamen^  meets  the 
condition.  otherwise,  the  first  qualifying  segment  in  the 
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preorder  traversal  (startina  from  the  beginninj  of  the 
occurrences  •♦:ree^  is  retrieved, 

Tr.  addition  to  settino  the  position  pointer,  this  command 
updates  tl®  poin te r- 1 o-paren t . 

Example: 

GlI  ’  r’MPLOYF^  ;  (MA.NN0=8  12)  ’ 

will  r'^turn  a  segmen*-  of  the  form  (KANNO,  dlHTHDAT^') 

where  >*ANNO  will  hav<=^  the  value  812,  {?1ANN0  is  an  acronym  for 
MAN  NUMP^P,) 

ii)  0?"^  N’^’XT 

GN  ’{;<srgmpnt  name>  {  ;  <quali f ication  expressio n>} )  ’ 

GN  retrieves  the  hierarchically  next  segment  of  th‘^ 

occurrences  tree.  By  starting  at  the  first  root  segment,  it 
is  possible  to  step  through  every  segment  in  a  iata  has^  by 
using  this  format  of  the  command, 

GN  ’  <segment  name>»  retrieves  the  next  <segmen*:  aame>  segment 
in  the  data  base.  All  ron-<segment  name>  sejnsnts  are 
disqualified  from  beirg  visited, 

GN  '<spqmert  na  me  > ;  <"  qua  1  i  f  ica  t  ion  expression>’  retrieves  the 
next  <segment  namr>  segment  with  qualification  <qu ali f ica t ion 
expression>.  All  non-<spgment  name>  segmen'^'s  as  well  as  all 
<segment  rame>  segments  not  meeting  <q uali f ica t i an 

expr^'Ssion>  are  disqualifiod  from  being  visit.  3d, 
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For  examole,  if  a  next  JOBHISTOFY  segment  exists,  it  can  1)=^ 
retrieved  by  issuing 

GN  '  JOB?II?TOFY' 

In  order  to  qualify  the  next  JOBHISTORY  segment  retrieved  to 
have  a  -job  date  earlier  than  JAN  1  1  9  32,  this  format  should 
be  used  : 

ON  MORFISTOFY;  (JOPDATFfJAN  1  1932)' 
iii)  NFX"^  WT'”T’IN  FAF^NT 

CN?  '  ffseqmert  naire>  (  ;  <qua  li  f  icat  ion  ex  press!  ori>}  }  ' 

Th'^  parent  within  which  segments  ar®  retrieval  bv  this 
command  is  established  by  the  last  GFT  UMIQM"^  or  GET 
issued . 

GNP  ''  retrieves  tpe  hierarchically  nex-^  segment  within  the 

naren  t , 

GNP  '<segment  rame>'  retrieves  the  next  <segment  name> 
segmen"^  within  the  parent.  ’^nsur*^  that  fsegment  narne>  is 
indeed  a  d^'sc'^nda  n  t  of  the  parent  and  not  an  ances'-.or. 

GNP  '  <3egm-'’r.  *:  na  m  e>  ;  <qua  1  i  f  icat  ion  expr^ssion>'  retrieves  the 
next  <s-^qment  naire>  segment  with  qualification  <  paaii  f  ica  tion 
expression^  within  he  parent.  Again,  <segra^nt  name>  must  be 
a  descendant  of  tpci  par^n,'^. 
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iv)  GFT  HOLO  UNTOUF, 

GHH  »<root  segra<=>nt  naipe>  ;<qaalif  ication  axpra3sion>’ 

GET  HOLE  ONIQUE  is  a  get-hold  coKmand  whioh  has  the  same 
arguments  as  the  normal  retrieval  command  -  GET  ’INI3UE.  In 
addition  to  retrieving  a  segment,  the  data  base  is  put  in  a 
hold  sta^rus  ready  -^or  modification  if  the  command  succeeds. 

V)  GF'^  HOLD  NEX'"' 

GKN  ’  {<segmert  name>  {  ;  <qual if ication  ex pre ssi on>} }  ' 

This  ge^-hold  command  has  the  same  arguments  as  the  normal 
retrieval  command  -  get  NEXT.  If  the  command  succeeds,  the 
data  base  is  placed  in  a  hold  status  ready  for  modification. 

vi)  GET  HOLD  NEXT  WITHIN  PARENT 

GHNP  * {<segment  name>  {  ;<qua lif icat ion  expression}}* 

This  command  has  the  same  arguments  as  the  normal  retrieval 
command  GE'^  NEXT  ET’^HIN  PARENT.  If  the  command  succeeds,  the 
data  base  is  placed  in  a  hold  status  ready  for  modification. 

lod if icat ion_Comm an ds 

Any  errors  detec-'-ed  ,  syntax  or  other,  while  executing  a 
modification  command  will  cancel  the  planned  update  and  remove 
the  hold  from  the  data  base,  necessitating  the  execution  of 
another  get-hold  command. 


On  succf^snftil  completion  of  a  modification  commani,  the  data 
base  is  automatically  unlocked  and  the  hold  removed. 

Only  complet^^  segments  may  be  replaced,  deleted  or  inserted. 

i)  P FPL ACE 

The  inf orma-^-i  on  in  the  buftor  area  replaces  the  segment 
obtained  by  the  preceedinq  get-hold  command.  Key  and  indexed 
fields  are  updated  if  necessary. 

The  data  in  the  buffer  area  replaces  the  entire  segment  and 
.  as  such  must  contain  data  that  is  compatible  rfith  the  total 
segment . 

F.g,,  in  order  to  update  the  salary  of  the  segment  with 
?ALARYDATE=jnNE  2  lOff  from  S55G  to  S700,  rhe  following 
procedures  should  be  followed: 

1)  GHN  »  SALAPYHTS^’OPY;  (SALARYDATS^JUNF  2  1956)’ 

This  retrieves  the  segment  to  the  buffer  area  and  puts 
the  data  base  in  hold  s'^atus  ready  for  modification. 

2)  nso  the  READ  and  WPI'”"  commands  and  to  change  S6S0 

to  E70C. 

3)  PEPLACE 

"^his  locks  -^he  data  base,  puts  the  corrected  segment 
back  into  the  data  base,  then  removes  the  lock  and  hold. 
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ii)  helETE 


A.ny  roo-*-  or  dspen'^ent,  segment  obtained  by  the  previous  get- 
hold  is  dele-t- ed  from  the  data  base.  All  descendants  of  this 
segment  are  also  deleted. 

iii)  INSEPT  ’  <5eginent  nameh' 

The  data  in  the  buffer  area  is  inserted  in  the  data  base  as  a 
^S'^'g  men-^  riame>  segment,  Th^  parent  of  <segment  naine>.  must 
previously  };ave  been  obtained  by  a  get-hold  command.  There 
must  be  enough  space  left  in  the  data  bas^  to  do  the 
insertion,  i.e.  ,  the  maximum  number  of  instances  under  a 
given  par<^nt  must  not  be  exceeded. 

As  root  segments  have  no  parent,  the  data  base  does  not  have 
to  be  placed  in  hold  wh^^n  inserting  them.  To  insert  a  root 
segment,  follow  these  steps: 

1)  Place  the  da^a  in  the  buffer  area. 

2)  Issue  the  command: 

INSFR'^  ’<root  segment  name>’ 


’buffer  Commands 


■"he  FEAD  and  utility  commands  are  provided  for  the 
purpose  of  accessing  the  information  in  the  buffer  area.  Their 
functions  should  be  obvious. 

The  syn-t-ax  for  the  monadic  function  ?EAD  is: 


{<APL  identifier>  <-}  READ  '  {<fiGld  nafne>i' 

ExamplG?; : 

{;<A^L  id9ntifier>  <-]  READ  »» 

retrieves  the  entire  segment  from  the  buffer  area  leaving  the 
data  in  internal  ED3S  format  (see  chapter  4) , 

{<APL  identifier>  FE.AD  •<field  name>* 

retriev-^s  the  value  of  the  <field  name>  field  from  the 
seqmen-t-  in  th^^^  buffer  area.  Conversions  are  performed 
au-^omatically.  Naturally,  <field  name>  must  be  a  valid  field 
of  the  segment  for  this  command  to  function  properly. 

The  syntax  f^xpressions  for  the  dyadic  WPITE  are: 

<value  or  .APL  identifier>  WRITE  *<sGg!nent  name>' 

and 

<valuG  or  A.PL  identifier>  WRITE  ^<field  narae>’ 

Examples: 

<value  or  APL  idf  ntifier>  W?I"'E  *  <segment  name>’ 

■^he  value  of  <value  or  APL  idcntifiGr>  replaces  the  entire 
segment  in  the  buffer  area.  The  format  oE  <value  or  APL 
identifier>  must  he  internal  EDBS  format,  since  no 
conversions  are  performed.  All  fields  are  checked  for 


validity  before  hfing  placed,  in  the  buffer  area 
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<valuf=  or  APL  idpr.tifier>  WRT'^F  *<field  name>' 

The  value  of  <value  or  APT.  iden^ifier>  replaces  the  current 
value  of  the  <field  nam“>  field  of  the  segment  in  the  buffer 
area.  rhecks  are  made  to  insure  that  <value  or  .APL 
identifier>  is  of  the  correct  data  type.  .Any  conversions  are 
automatically  performed. 

The  error  messages  are  classified  according  to  one  of  the 
five  types  of  errors  that  can  occur. 

1)  Condi;^i2ns 

Certain  conditions  arise  during  retrieval  which  are  not 
necessarily  errors,  but  are  situations  of  which  the  user  may 
want  to  b<^  informed.  In  such  cases,  no  error  message  is 
DL'inted  out.  The  variable  STA.TUS  is  set  to  one  of  several 
values  as  indicated  earlier  in  this  chapter. 

2)  Syntax  Frrors 

These  errors  occur  because  a  required  part  of  an  argument  in 
a  command  is  missing.  The  error  messages  are  self  explanatory 
and  will  not  be  elaborated  further.  In  all  cases  the  command 
argument  is  printed  out  and  the  position  in  the  argument 
where  the  error  was  discovered  is  indicated.  These  are  fatal 
errors  and  cause  a  command  to  fail. 

1)  f^ISSINC  nATA  B.AS  F  N.A^F 


2)  TISSINC  SEGMENT  NA'^E 
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3) 

MISSING 

SEGMENT  OR  FIELD  NAME 

4) 

MISSING 

OUALIEICA'^ION  EXPRESSION 

MISSING 

'  (' 

6) 

MISSING 

')  ’ 

7) 

MISSING 

FIELD  NAME 

B) 

MISSING 

CONDITIONAL  OPERATOR 

B) 

MISSING 

OR  INVALID  CONDITIONAL  OPERATOR 

1C) 

MISSING 

FIELD  VALUE 

1  1) 

MISSING 

‘AND’  OR  ’OP' 

12) 

MISSING 

MONTH  IN  DATE 

13) 

MISSING 

DAY  TN  DATE 

14) 

MISSING 

YEAR  IN  DATE 

15) 

MISSING 

1  .  1 

9 

3)  Invalid  Arguments  or  Data 

These  errors  occur  either  because  faulty  data  was  aatered  or 
because  the  data  entered  did  not  meet  EDES  restricrians.  In 
all  cases  the  command  argument  is  printed  out  and  the 
position  in  the  argument  where  the  faulty  data  was 
encountered  is  flagged, 

1)  INVALID  APGUr'ENT  IN  OPEN  COMMAND 

2)  INVALID  ^RGNMEN^  TN  CLOSE  COMMAND 

3)  INVALID  ARGUMENT  IN  INSERT  COMMAND 

4)  INVALID  ARGUMENT  IN  READ  COMMAND 

5)  INVALID  ARGUMENT  IN  WRITE  COMMAND 

6)  INVALID  DATA  EASE  NAME 

I)  INVALID  SEGMENT  NAME 

3)  INVALID  S^GM^NT  OR  FIELD  NAME 
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9)  INVALTT)  FI?LD  NAMF 

The  above  errors  occur  because  something  more  than  the 
required  argument  was  supplied.  Arguments  to  all 
commands  must  follow  the  format  specified  in  the  syntax 
for  -'-ha-^  command.  Names  must  be  valid  data  base,  segment 
or  field  names.  Error  8  can  also  occur  in  a  WPIT’^ 
command  if  the  segment  or  field  name  is  not  compatible 
with  the  segment  in  the  buffer. 

10)  DATA  EASE  NAFF  TOO  LONG 

11)  SFGNFNT  NAMF  TOO  LONG 

12)  S^GNENT  OP  FIELD  NAME  TOO  LONG 

13)  FIELD  NAMF  *^00  LONG 

Data  base  names  must  be  10  characters  or  less  in  length. 
Segment  and  field  names  can  have  a  maximum  of  20 
cha  racters. 

14)  SEGMFNT  NOT  A  SEGMENT  OF  THIS  DATA  RASE 

15)  FIELD  NOT  A  FI^LD  OF  THIS  SEGMENT 

The  segment  (field)  name  is  not  a  segment  (field)  of  the 
data  base  (segment). 

16)  SEGMFNT  NOT  A  FOOT  SEGMENT 

In  a  GH  or  GHU  command,  the  segment  must  be  a  root 


segment 
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17)  SEGf^FNT  NOT  WITHIN  PEEVIOUSLY  ESTABLISHED  PARENT 

In  a  GNP  or  GHNP  command  which  specifias  a  <segmGnt 
name>,  the  segment  name  must  be  a  descendant  of  the 
established  parent. 

18)  SEGMENT  NOT  A  SON  OF  THE  SEGMENT  SPECIFIED  IN  GST  HOLD 

In  an  INSERT  command  (except  for  root  segments) ,  the 
<segment  narae>  specified  must  be  a  son  (first  level 
descendant  only)  of  the  segment  obtained  in  the  GET  HOLD 
command. 

19)  KEY  OF  SEGMENT  NOT  UNIQUE 

In  a  EEPLA-CR  or  INSERT  command,  the  kGy(3)  of  the 
segment  must  be  unique  for  the  segment  type  either 
within  the  data  base  for  the  root  segments  or  within  the 
parent  for  dependent  segments. 

20)  INVALID  SEGMENT  IN  BUFFER 

A  REPLA.CE  or  INSERT  has  detected  an  invalid  segm<='nt  in 
the  buffer.  The  segment  in  the  buffer  area  must  be 
compatible  as  to  field  length  and  type  with  the  segment 
type  to  be  inserted  or  replaced. 

21)  INVALID  SEGMENT 

A  WRITE  ’<segment  narae>'  command  has  detected  that  the 
segment  supplied  is  not  compatible  as  to  field  length 
with  the  <segment  name>  specified. 
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22)  INVALID  CONDITIONAL  OPERATOR.  CONDITIONAL  OPERATOR  MUST 
BF  =  OF  "='OF  S'^PINOS. 

2  3)  INVALID  PATE  ’^lEID 

24)  INVALID  NUMERIC  FIELD 

25)  INVALID  STRING  FIELD 

Date  fields  supplied  to  a  WRITE  *<sGgment  name>'  coEmani 
must  be  in  the  format  indicated  in  chapter  4.  Numeric 
fields  supplied  as  character  strings  must  contain  only 
numbers,  +,  and  decimal  point.  String  fields  may  only 
contain  those  characters  indicated  in  chapter  4. 

26)  INVALID  MONTH  TN  DATE 

2V)  INVALID  DAY  IN  DATE 

2R)  INVALID  YEAR  IN  DATE 

29)  INVALID  DATE 

30)  NUMERIC  VALUTA  EXCEEDS  t='IELD  WIDTH 

31)  STRING  LENGTH  EXCEEDS  FIELD  WIDTH 

In  the  last  two  messages,  either  the  number  of  digits  in 
a  number  or  the  number  of  characters  in  a  string  exceeds 
thf^  field  width  specified  in  the  data  definition 
specification  for  the  data  base. 

4)  L23.ic_Frrors 

These  errors  arise  because  the  user  has  failed  to  fulfill  or 
check  for  certain  conditions  before  issuing  a  command  or 
because  of  restrictions  olaced  on  the  user  in  the  type  of 
access  he  is  allowed. 
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1)  INV;^LID  COMf^^^ND.  NO  DATA  BASE  CnSRENTLY  OPEN. 

The  user  has  failed  to  open  a  data  base  befor3  issuing 
an  EDBS  coDBinand. 

2)  <data  base  name>  DATA  BASE  NOT  PERMITTED  TO  BE  ACCESSED. 

The  user  is  not  allowed  to  access  this  data  base. 

3)  <data  base  na[ne>  NOT  PREVIODSLY  OPENED. 

The  user  has  attempted  to  close  a  data  base  that  has  not 
been  opened. 

4)  PREVIOUSLY  OPENED  DATA  BASE  NOT  CLOSED  OR  FILE  TIE 
NUMBERS  1  -  1C  IN  USE 

The  user  has  attempted  to  open  another  data  base  without 
first  closing  the  currently  open  data  base  or  has  used 
file  tie  numbers  1  -  10  to  tie  a  user  file. 

5)  <data  base  narae>  DATA  BASE  NOT  FOUND. 

*  » 

The  data  base  is  not  in  the  system. 

6)  <data  base  name>  DATA  BASE  CANNOT  BE  ACCESSED 
HIERARCHICALLY. 

The  user  has  attempted  to  open  a  data  base  which  can 
only  be  accessed  by  the  relational  subsystem. 
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7)  <data  base  r.ame>  DATA  BASE  SEGMENTS  NOT  PERMirrED  TO  BE 
REPLACED. 

The  user  is  not  allowed  to  issue  a  REPLA.CE  command  on 
the  data  base. 

R)  <data  base  name>  DATA  BASE  SEGMENTS  NOT  PERMITTED  TO  BE 
INSERTED. 

The  user  is  not  allowed  to  issue  an  INSERT  command  on 
the  data  base. 

P)  <data  base  name>  DATA  BASE  SEGMENTS  NOT  PERMITTED  TO  BE 
DELETED. 

The  user  is  not  allowed  to  issue  a  DELETE  command  on  the 
data  base. 

1C)  <data  base  name>  DATA  BASE  NOT  PERMITTED  TO  BE  PLACED  IN 
HOLD. 

The  user  is  not  allowed  to  issue  a  GET  HOLD  command  on 
the  data  base. 

11)  <data  base  name>  DATA  BASE  NOT  PREVIOUSLY  PLACED  IN 
HOLD. 

The  user  has  attempted  to  do  a  modification  without 
first  placing  the  data  base  in  hold. 
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12)  <data  base  name>  DATA  BA5^  ALREADY  IN  HOLD.  HOLD 
CANCELLED. 

The  user  has  issued  a  GET  HOLD  command  on  a  data  base  he 
already  has  in  hold.  The  hold  is  cancellei. 

13)  <data  base  name>  DATA  BASE  IN  HOLD.  NO  READS  PERMITTED. 
HOLD  CANCELLED. 

A  user  is  not  allowed  to  read  a  data  base  he  has  in 
hold.  The  hold  is  cancelled. 

14)  NO  POSITION  ESTABLISHED  IN  THE  DATA  BASE.  A  GET  UNIQHE 
IS  REQUIPED. 

In  order  to  establish  a  position  in  the  data  base,  the 
first  command  required  is  a  GET  UNIQUE. 

15)  <seqment  name>  MAXIMUM  NUMBER  OF  OCCURRENCES  EXCEEDED. 

In  attempting  to  do  an  INSERT,  the  maximum  number  of 
occurrences  of  a  segment  type  within  a  parent  has  been 
exceeded . 

16)  NO  SEGMENT  IN  BUFFER 

A  REPLA.CE  or  INSERT  command  has  detected  that  the  buffer 
area  is  emoty. 
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17)  TJSF7  LOCKED  OUT.  SEE  DEMONSTRATOR. 


On  his  previous  sign-off,  the  user  did  not  slose 
data  base  he  had  open.  The  user  will  be  unable  to  as 
any  data  base  until  the  condition  is  brought  to 
attention  of  a  demonstrator. 

1R)  DATA  BAS^  NOT  AVAILABLE.  DATA  BASE  MAINTENANCE 
5)  Sy stem_Errors 


These  errors  should  never  occur.  If  they  do,  bring  the 
the  attention  of  a  demonstrator  immediately  along  with 
command  which  caused  the  error  to  occur. 


1) 

SYSTEM 

ERROR . 

DATA  BASE 

FULL. 

2) 

SYS'^EM 

ERROR. 

INTEGRITY 

CHECK  -  RETRIEVAL 

3) 

SYSTEM 

ERROR. 

INTEGRITY 

CHECK  -  DELETION. 

>i) 

SYSTEM 

ERROR. 

INVERTED 

LIST  OVERFLOW. 

the 

cess 

the 


m  to 
the 
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22i2.ti2I13.1_SiibsY3tein 

\  relational  data  base  is  a  tabular  data  structure  cansisting 
of  L§i^fi2I12  identified  by  unique  relation  names.  Fach  relation 
can  itself  be  viewed  as  a  table  with  a  fixed  number  of  columns 
and  a  variable  number  of  rows.  The  columns  are  called  domains  and 
the  rows  are  called  tu^lfs.  No  ordering  of  the  tuples  is  defined. 

In  mathematical  terms,  a  relation  is  defined  to  be  a  subset 
of  the  Cartesian  product  of  its  domains. 

21S.d id ate_kex  of  a  relation  is  a  minimal  combination  of 
domains,  possibly  a  single  domain,  such  that  by  specifying  the 
relation  name  and  a  candidate  key,  a  unique  tuple  of  the  data 
base  is  identified. 

In  each  relation,  one  candida-^e  key  is  specified  by  the  data 
base  administrator  to  be  a  primary_keY.  A.11  primary  key  domains 
are  kept  as  inverted  lists  to  aid  in  the  searching  of  the  data 
base.  An  inverted_list  for  a  domain  consists  of  all  the  different 
data  items  in  that  domain  along  with  pointers  into  the  data  base 
where  they  occur. 

An  a  domain  (not  in  the  candidate  key)  for 
which  an  inverted  list  is  maintained. 

See  chapter  5,  Pelational  View  of  Hierarchies  section,  for  an 
explanation  of  how  hierarchical  data  bases  can  be  viewed 
relationa lly. 


In  the  explanation  of  the  commands,  the  following  terms  will 
be  used: 

<relation  name> 

Replace  every  occurrence  of  <relation  name>  with  a  valid  data 
base  relation  name.  It  must  be  a  valid  EDBS  variable  up  to 
characters  in  length. 

<domain  name> 

Replace  every  occurrence  of  <domain  name>  with  a  valid  domain 
name  of  the  relation  in  guestion.  It  must  be  a  valid  FOBS 
variable  ud  ro  2C  characters  in  length. 

<data  base  name> 

Replace  every  occurrence  of  <data  base  name>  wi-^h  the  name  of 
an  existsinq  data  base.  It  must  be  a  valid  EDBS  variable  up 
to  10  characters  in  length. 

<target  list> 

The  expression  ^target  list>  is  a  short  form  for  ono  or  more 
occurrences  of 

<relation  name>  {.<domain  name>} 

separated  by  commas.  This  format  is  used  to  specify  exactly 
which  domains  are  to  be  retrieved  from  the  da^a  base.  Tf 
<relation  name>  appears  without  <domain  name>,  then  all 
domains  of  that  relation  are  retrieved  to  the  buffer  area; 
otherwise,  the  single  domain  specified  is  retrieved. 
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If  two  differon'^  rolatiori  r.amos  appear  in  <tar7et  iLst>,  then 
a  qualification  in  the  form  of  a  join  condition  (explained  in 
<qualif  ication  expressiori>  part)  must  appear  in 
<gua lif ication  expressior.>,  with  the  added  restriction  that 
the  relation  names  that  appear  in  <target  list>  must  be  the 
same  as  those  in  the  join  condition. 


<limi t> 

The  expression  <limit>  is  to  be  replaced  by  any  positive 
integer.  Since  more  than  one  tuple  can  be  retrieved,  <limit> 
allows  users  to  select  only  as  many  of  those  tuples  as  they 
desire.  If  <limit>  is  not  specified,  all  qualifying  tuples 
are  returned;  otherwise,  the  first  <limit>  qualifying  tuples 
are  retrieved. 

<conditional  operator> 

^11  of  <,  <,  =,  >  and  >  are  conditional  operators  which 

can  be  used  to  qualify  retrieved  data  from  the  data  base, 

<value> 

The  expression  <value>  is  to  be  replaced  by  any  number,  date 
or  strina.  See  chapter  4  -  Data  Formats  section. 

<qua li f ication  expression> 

A.S  in  the  hierarchical  subsystem,  <quali  f  icaticn  expression> 
is  used  to  qualify  retrieved  data.  It  may  have  either  of  the 
following  "^orms: 


(<rGlation  na me>.  <domain  nameXcondit ional  operatorX  value>) 
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called  a  sim2le_condi tion,  or 

(<relatior,  name>,  <doinain  naine>=<re lat ion  name>.  <doraain  name>) 
called  a  join  condition. 

There  may  he  more  than  one  occurrence  of  such  conditions, 
providing  that  they  are  connected  with  the  logical  connectors 
AND  or  OP,  ■  This  compounding  of  the  simple  condition  is 
called  a  compound  condition. 

Parentheses  may  be  used  to  change  the  order  of  evaluation  of 
the  expression;  otherwise,  AND’s  are  evaluated  before  OR's, 

For  relational  retrievals  on  hierarchical  data  bases,  the 
join  condition  may  appear  only  once  in  a  <qualif ica tion 
expression>,  and  must  specify  2  different  relation  names  and 
the  same  domain  name.  However,  on  relational  data  bases,  the 
number  of  join  conditions  is  not  limited,  and  they  roo  must 
be  joined  by  the  logical  connectors  AND  or  OR.  In  this  case, 
tho  domains  in  "^he  join  must  be  of  the  same  typ'^  only,  i.e., 
must  bo  date,  string  or  numeric. 

The  domain  in  the  join  condition  must  be  an  indexed  or 
primary  key  domain. 

Con trol_Coramands 

The  relational  control  commands  are  identical  to  those  for 
the  hierarchical  subsystem. 
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i)  OP’^N 

The  format  of  the  open  control  command  is: 

OPFN  '<data  base  name>’ 

The  command 

OPFN  *CO?iPA-NY' 

will  open  the  data  base  COMPANY  as  described  in  chapter  4. 

ii)  v'^LOSF 

The  close  control  command  is: 

CLOSF  ’<data  base  name>’ 

Make  sure  tha-*-.  <data  base  name>  is  the  same  data  base  name 
used  in  the  corresponding  open  control  command. 

CLOSE  'COMPANY* 

will  close  the  data  base  COMPANY. 

iii)  PSLFASE 

The  release  command  has  no  arguments  and  app=‘ars  as: 


PELEAS^ 

It  must  be  used  whenever  a  get-hold  has  been  issuad,  but  no 


modification  is  going  to  follow 


Retrieval  Commands 

Relational  retrievals  return  0  or  more  tuples  to  the  buffer 
area.  The  tuples  in  the  buffer  area  can  be  read  or  modified 
using  the  READ  and  WRITE  commands  explained  in  this  chapter. 

The  number  of  actual  tuples  retrieved  is  available  from  the 
system's  niladic  function  TUPLES. 

If  a  syntax  error  is  detected  in  a  comraanl/  then  the 
retrieval  fails  -  no  tuples  are  returned,  the  buffer  area  is 
cleared  and  STATUS  tabes  on  the  value  1. 

However,  it  is  possible  that  no  tuples  are  retrieved,  but 
STATUS  has  the  value  C,  meaning  that  the  retriaval  succeeded. 
This  condition  indicates  the  absence  of  syntax  errors  ia  the 
command,  but  that  no  tuples  meeting  the  qualifications  can  he 
found . 

Before  continuing,  it  might  be  helpful  to  explain  that  what 
is  referred  to  as  a  tuple  stored  in  the  buffer  area  is  not 
necessarily  a  complete  tuple  of  information  as  snored  in  the  data 
base  and  described  earlier  in  this  chapter.  The  values  and  order 
of  the  tuples  in  the  buffer  area  come  only  from  the  loiains  and 
order  specified  in  the  target  list  of  the  command  which  retrieved 
t  hem. 


For  example,  all  th“  followirq  can  be  considered  to  be  tuples 
stored  in  the  butfer  area,  '^hey  are  taken  from  the  data  base 


COMPANY : 


(JONES  F) 


(JONES  F,  812) 

(812,  JONES  F,  JULY  10  1930) 

Only  the  last  one  is  a  complete  EMPLOYEE  relation  tuple.  The 
domains  are  (KAN^’O,  PIPTHPATF)  . 

It  should  be  noted  that  not  all  of  the  example  tuples  could 
be  in  the  buffer  area  at  the  same  time,  as  each  requires  a 
different  <target  lis^>. 

There  are  two  relational  retrieval  commands  GET  and  GETHOLD. 
i) 

The  format  of  the  GET  command  is; 

GET  '  f<limit>;}  <target  list>  {; <gua lif ica tion  9XDressiDn>} ' 

This  command  retrieves  zero  or  more  tuples  (not  necessarily 
complete  relational  tuples)  specified  by  <tar7et  li3t>,  which 
are  placed  in  the  buffer  area.  The  retrieval  may  be  qualified 
so  that  only  a  certain  maximum  number  of  tuples  -  <limit> 
are  returned,  or  so  that  only  certain  required  specifications 
-  <qua lif icat ion  expression>  -  be  met. 

If  the  target  list  does  not  specify  all  th^'  domains  in  the 
stored  relation  then  the  retrieved  tuples  may  have  duplicates. 
The  duplicate  tuples  are  not  removed. 
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Fxamples: 

GFT  ’f^MPLOy^F* 

returns  set  of  all  tuples  (MANNO,  NAMF,  BIRTHDATF)  of  the 

relation  ^Mpi.nyE^. 

GFT  ’  F?1  PLOY  ^F.  NAME,  EK  PLOY  EE.  MAN  NO  ' 

re'*’urns  all  the  employees*  names  and  their  man  numbers, 

GET  'CFILPFFN.  CHILDNAKF;  (CHI LD RE N . M ANK0  =  3 1 2 )  ’ 

returns  the  nam<^s  of  the  children  of  the  employee  with 
MANN0=S12. 

GFT  ' JOPHTS^O^Y. TITLE,  SAIARYHISTOPY. SALARY; 

(JOBHISTOPY. MANNO=SALARYHISTORY. MANNO) ' 

returns  all  •*:h^^  titles  and  salaries  that  everyboly  ia  the 
■lata  base  has  ever  had. 

GET  'JOPHIFTOFY.  TITLE;  (JOBHI-STORY.  MANNO=S12)  AND 
(JOBHISTOPY. JOEDATE>APP  31  1955)' 

returns  the  job  titles  that  the  employee  with  MANN0=812  has 
had  since  APF  11  1955, 

ii)  G^THOLD 

The  GFTHOLP  format  is: 


GETHOLD  '  [<limi+>;}  <target  list>  {; <qua lif ica tion  expression>}  ' 
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This  command  re+rieves  0  or  more  tuples  to  the  buffer  area. 
There  is  a  restriction  though,  that  two  different  relation 
names  may  not  he  specified  in  <target  list>. 

A.S  this  is  a  get- ho  Id  command,  enough  information  is  kept  by 
the  system  to  perform  an  update,  and  the  data  base  is  placed 
in  hold  status. 

Remember  to  follow  GETHOLD  with  an  update  command  or  a 
release  command. 

Examples  of  this  command  are: 

GETHOLD  » 6 ;EKPLOYFE. EIPTHDATE' 

This  will  retrieve  the  birthdates  of  the  first  6  employees 
found  and  put  the  data  base  in  hold.  Remember,  the  relational 
tuples  have  no  ordering  in  the  data  base  -  the  5  employee 
tuples  could  just  as  well  be  chosen  randomly. 

GETHOLD  ’CHILDREN;  {CHILDREN.  CHILDNA?!E  =  PAHL)  ' 

This  will  re-^urn  complete  CHILDREN  tuples  with  CKILDNAME=  PAUL 
to  the  buffer  area  and  put  the  data  base  in  hold.  There 
be  zero  or  more  of  these  tuples. 


may 
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l^od if icat ion  Commands 


In  the  relational  system,  only  the  update  command  is 
preceeded  by  a  get-hold.  The  insert  and  delete  commands  work 
alone  and  may  not  be  preceeded  by  a  get-hold, 

\r  y  error  detf^cted  will  cancel  the  modification  and  remove 
the  hold  from  the  data  base. 

On  successful  completion  of  a  modification,  the  data  base  is 
automatically  unlocked  and  the  hold  removed. 

i)  OPDATf 

Havina  upda'^-ed  the  appropriate  values  in  the  buffer  area,  the 
command 


UPDATE 


is  issued.  This 
replace  the  values 
iust  prior  to  rhe 
updated  need  to  be 


caus'^s  ■’■he  values  in  the  buffer  area  to 
that  were  retrieved  from  the  data  base 
upda-'-e.  Only  those  domains  which  are  to  be 
retrieved  in  the  preceedin^  get-hoid. 


inverted  lists  are  main-gained  and  updated  as  necessary. 


Type  checking  of  the  data  is  done -and  if  an  error  is  found, 
no  part  of  the  update  is  performed. 
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ii)  PUT 

With  the  command 

PU*^  *  {<3imit>  ;  }  <r<^lation  name>’  , 

a  new  relational  tuple  or  up  to  <limit>  tuples  are  inserted 
in  the  <rGlation  na[ne>  relation.  The  system  checks  if  enough 
space  is  left  in  the  relation  to  do  the  insertion,  since  th^ 
maximum  number  of  tuples  allowed  must  not  be  exceeded.  It 
also  type  checks  the  data  to  insure  that  only  proper  format 
information  is  stored  in  the  data  base. 

Tf  a  syntax  error  is  detected  or  ther^  is  no  space  available 
for  the  insertion,  the  command  fails  (STATUS  ejuals  1),  the 
buffer  area  is  no^  cleared,  and  an  explanatory  error  message 
is  printed  on  the  terminal. 

iii)  DPL^TP 

The  command 


DELETE  ’<relation  na me> ; <gua li f ication  expression>’ 

deletes  a  <relation  name>  tuple  with  qualification 
<qualif ication  expression>  from  the  data  base. 

It  has  the  restric-^ion  that  the  <qua li  f  ica tion  axpressionP 
must  only  qualifiy  one  relation  in  the  data  base.  Of  course, 
the  <relation  name>  in  the  <gua li f ica tion  expres3ion>  must  be 
the  same  as  <relation  name>  in  the  DELETE  command. 
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f  ^r_Commands 

There  are  two  commands,  ^READ  and  WPITE,  provided  for 
manipulating  data  in  the  buffer  area. 

The  syntax  for  is: 

{<API  identifi‘^r>  <-}  READ  '{<relation  name> .  <doma  in  name>} 

{  ;  <specif icat ion>} • 

The  syn-^ax  for  WPITE  is: 

<value  or  APL  identifier>  WPIT^  ’  {<rGlation  nam3>. 

<domain  name>}  {  ;  <specif ication>} ’ 

where  <specif ica tion>  is  a  series  of  integer  numbers  ia  any 
order,  separated  by  commas,  which  gives  the  tuple  numbers  of  the 
desired  tuples  in  the  buffer  area,  i.e.,  first  tuple,  second 
tuple,  etc. 

Examples: 

{;<APL  idGr.tifier>  <-}  READ  ” 

All  the  tuples  in  the  buffer  area  are  retrieved  and  placed  in 
the  variable  <'APL  identifier>.  No  conversions  are  performed. 
If  the  buffer  area  contains  more  than  one  tuple,  the  form  of 
<APL  iden+ifier>  is  an  n  by  m  matrix,  where  n  is  the  number 
of  tuples (rows)  and  m  is  the  character  string  length  of  each 
tuple.  (In  domains  of  type  date,  m  will  always  be  8.) 
□  ■t-herwise,  <APL  identifier>  is  a  character  string  value 
(vector),  cor-^ain.ing  only  a  single  tuple  value. 
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(<APL  identifier>  <-}  PEAD  ' <spGcif ica tion> ' 

The  tuples  indicated  by  <specif ication>  are  retrieved  and 
placed  in  <APL  identifier>.  The  form  of  <APL  identifier>  is 
an  n  by  m  matrix  or  a  vector ,  depending  on  how  many  tuples 
are  specified.  Again,  no  conversions  are  performed,  and  the 
data  remains  in  internal  EDES  format. 

(<APL  identifier>  READ  ’<relation  name>  .  <domain  name>' 

The  <domain  name>  value  is  retrieved  from  all  tuples  in  the 
buffer  area.  Any  conversions  required  are  performed.  If  the 
domain  is  numeric,  then  the  <value  or  API  identifier>  will  be 
a  vector  of  numbers  with  one  numeric  element  per  value.  If 
the  domain  is  of  type  date  or  string,  then  the  result  is  an  n 
by  m  matrix  where  n  is  the  number  of  tuples  in  the  buffer 
area  and  m  is  the  width  of  the  domain.  The  order  of  the 
values  in  <A.PL  identifier>  is  the  same  as  when  retrieved  from 
the  data  base. 


C<APL  idGntifier>  <- 


PEAD  ’<relation  name>  .  <domain  name>  ; 

<SDecification>’ 


H ere ,  as  in  the  previous  example,  <domain  name>  values 
retrieved  from  the  buffer  area  and  placed  in 
identifier>,  the  only  difference  being  that  the  <domain  n 
values  are  taken  only  from  the  list  given  in  <specificati 
Data  type  conversions  are  performed  automatically. 


are 

<A?L 

ame> 

on>. 
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<value  or  API,  idp nt if ier>  WPITF  *’ 

The  contents  of  <APL  identifier>  overwrite  the  buffer  area, 
clearing  whatever  is  not  overwritten.  If  <APL  identifier>  is 
a  matrix,  then  ®ach  row  of  <APL  identifier>  becomes  one  tuple 
in  the  buffer  area.  The  format  of  each  row  of  <APL 

idGntifier>  must  be  the  same  as  the  internal  tuple  format  of 
FDBS,  i.e.,  string  data  with  domains  properly  aligned.  No 
conversion  or  checking  is  done  at  this  stage. 

<valuG  or  APL  identifier>  WPI'^E  *<r9lation  name>.  <domain  name>' 

Each  row  of  <APL  identifier>  replaces  the  <doraain  ndrae>  value 
in  the  corresponding  tuple  of  the  buffer  area.  Consaquently , 
there  must  be  as  many  rows  in  <APL  identifier>,  as  there  are 

tupl‘=s  in  the  buffer  area,  with  one  exception  if  <APL 

identifier>  is  single  valued,  then  the  <doraain  naine>  values 
of  all  tuples  are  changed  to  that  one  value  of  <APL 

identifier>.  Any  conversions  necessary  are  performed 
automatically.  No  WRITE  occurs  unless  all  values  are  valid. 

<value  or  APL  identifierA  WF  ’  <relation  name>. 

<domain  nameA; <specif ication> * 

The  same  conditions  apply  here  as  for  the  previous  WRITE 


exam  plf 

with 

th  e 

excep-^ion  that 

t  he 

domains  of 

on  1  y 

t  hosp 

tuples 

listed 

in 

<specification> 

are 

overwritten. 

Ag  i  i  n 

,  <AP  L 

identifier>  must 

have  as  many 

rows 

as  there 

are 

tu  pies 

specified  in  <'specif  ica-^  ion>.  Otherwise,  the  single  value  of 
<APL  identifier>  replaces  all.  of  the  <domain  name>  values  in 
the  tuples  indicated  by  <specif icat ion>. 
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lati  onal_?ubs}fst  pm_Er  ror_Messa3:2i 

The  error  messages  can  be  classified  into  three  classes  -- 
syntax  errors,  invalid  arguments  or  data  and  other  errors. 

Syn  t  a  X  _  E  r  r  o  r  s 

These  errors  are  detected  when  the  argument  to  a  command  does 
not  follow  the  syntax  set  out  for  them.  The  first  line  of  the 
message  is  syntax  ERROR:  This  is  followed  by  an 

indication  of  where  the  error  was  detected.  The  error  message  is 
concluded  with  the  line: 

VALID  ALTEPNATIVFS  APE:  <alt er nati ves>'’ 

A  list  of  the  possible  alternatives  which  may  appear  in  the 
syntax  error  messages  follows: 

1)  •  ;* 


2) 

TARGET  LIST 

3) 

•OR',  '?.ND' 

• ; ’ ,  OR  END  OF 

ARGUMENT 

4) 

' ; *  OR  END 

or 

ARGHMENT 

5) 

II  II  1 

•  f  ft 

.  1 
f 

OP  END  OF  ARGUMENT 

6) 

•;•  OR 

END  OF  ARGUfiENT 

7) 

*  (' 

8) 

•)  ’ 

9) 

1  1 

• 

10) 

1  <  1  1  <  1  1 
^  /  -  r 

=r  1 

,  •>  » ,  *  >»  OR  * 

11) 

A  NbriBFR 

12) 

QIIALIFICA""! 

ON 

EXPRESSION 
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I  n  val  id_Arg^umen  ts_or_Data 

In  this  type  of  error  the  user  has  satisfied  tha  command 
syntax  but  has  supplied  an  invalid  name  or  invalid  data.  The 
different  error  messages  follow: 

1)  <name>  IS  NOT  A  VALID  RELATION  NA^^E 

2)  <name>  IS  NO""  A  VALID  DOMAIN  OF  <relation  name> 

3)  DOMAINS  <relation  na m e> .  <doma in  name>  AND 
<relation  name>, <domain  name>  HAVE  DIFFERENT  TYPES 

The  user  has  attempted  to  join  two  relations  on  domains 
which  are  in  com  pa t ibl e. 

h)  <relation  name>. <domain  name>  IS  OF  TYPE  (DATE,  NUMERIC 
or  STPINO]  WHICH  IS  INCoypATIELE  WITH  <value> 

5)  A  {>,  <,  <,  or  >}  COMPARISON  CANNOT  RE  MADE  ON  DOMAINS 
OF  TYPE  STRING 

6)  THE  INPUT  TO  FUNCTION  WRITE  MAY  NOT  HAVE  KOR-  THAN  TWO 
DIMENSIONS 


7) 

THE 

i*  TH 

DATA 

ITEM 

IS 

NOT  OF  TYPE 

(DATE 

or  STRING} 

3) 

THE 

i  '  TH 

DATA. 

ITEM 

IS 

TOO  LONG 

7) 

THE 

i  '  "’H 

DATA 

ITEM 

HAS 

TOO  MANY  DIGITS 

10) 

THE 

INPU"^ 

TUPLES  HA 

.V"" 

A  DIFF""RENT 

WIDTH 

THAN  THE  TUPLES 

IN  THE  BUFF""? 


This  error  occurs  when  the  user  attempts  to  replace 
some,  but  nor  all,  o^  the  tuples  in  the  buffer  and  the  new 
tuples  are  of  a  different  width  than  the  old  ones. 

11)  <name>  is  NOT  A  DATA  EASE  NAME 

12)  <data  base  name>  CANNOT  BE  VIEWED  RELATICNALLY 

13)  <data  base  name>  IS  NOT  RELATIONAL  —  thtS  WORKS^’ACE 


ONLY  HANDLES  RELATIONAL  DATA  BASES 


Other  Furors 


This  class  comprises  various  logic  errors  aril  system 

limitations.  "^he  messages  follow: 

1)  FILE  TIE  NTTEPFPS  1  TO  6  NOT  FRFF 

The  user  has  attempted  to  open  the  data  base  while  using 
file  tie  numbers  in  the  range  1  to  6. 

2)  DATA  BASE  NOT  OPENED  OP  SYSTEM  l='ILES  HAVE  BEEN  HNTIED 

If  the  data  base  was  not  opened  then  the  user  should 
open  the  data  base  and  re-issue  the  command.  If  system  files 
were  untied,  explicitly  or  by  signing  off  without  closing  the 
data  base,  then  the  user  will  be  locked  out  of  FD3S  and  must 
see  his  demonstrator. 

3)  NO  MOPE  THAN  2  PFLATIONS  MAY  BE  USED  IN  A  RETRIEVAL 
COMMAND 

4)  NO  MOPE  THAN  1  RELATION  MAY  BE  USED  IN  A  MODIFICATIDN 
COMMAND 

5)  BOTH  DOMAINS  IN  A.  JOIN  MOST  BE  INDEXED.  <relation  name>. 
<doroain  name>  IS  NO”^ 

6)  NO  MORE  THAN  ONE  JOIN  IS  ALLOWED  IN  A  QUALIFICATION 
T^-XPRESSION 

•^his  only  applies  when  hierarchic  data  bases  are  viewed 
rela tiona lly . 

7)  CANNOT  '^A.KE  THf  UNION  OF  A  JOIN  EXPRESSION  WITH  A  SIMPLE 
ONE 

This  only  applies  when  a  hierarchic  data  base  is  viewed 
relationally. 

8)  A  RELATION  MAY  NOT  BE  JOINED  WT'^H  ITSELF 

9)  A  JOIN  IS  MISSING  FROM  THE  QUALIFICATION  EXPRESSION 
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The  user  has  used  two  different  relations  in  the  same 
GFT  command  but  has  not  joined  them. 

1C)  AT  MOST  ONE  DOMAIN  MAY  BE  SPECIFIED  IN  THE  TARGET  LIST 
OF  A  {P.'='AD  or  WRITE} 

11)  DOMAIN  <relation  name>. <domain  nams>  WAS  NOT  RETRIEVED 
IN  THE  PREVIOUS  GFT 

■^he  user  has  specified  a  domain  in  the  target  list  of  a 
READ  or  WPI"'F  command  but  that  domain  was  not  retrieved. 

12)  TUPLE  SPECIFICATION  IS  GREATER  THAN  THE  NUMBER  OP  TUPLES 

ETRIEVED 

In  the  tuple  specification  list  of  a  READ  or  WRITE 
command  the  user  has  specified  a  tuple  number  greater  than 
the  number  of  tuples  in  the  buffer 

13)  THE  DOMAINS  OF  TH^  BUFFER  APE  UNKNOWN 

The  user  has  specified  a  domain  in  a  READ  or  WRITE 
command  after  the  buffer  has  been  overwritten  using  the 
command:  WPITE  ' {<specif ica tion>} ’ 

14)  THE  NUMBEF  OF  TUPI.ES  IN  THE  INPUT  DOES  NOT  MATCW  the 
NUMBER  IN  ’^IIF  SPECIFICATION 

15)  THE  NUMBFF  OF  TUPLES  IN  THE  BUFFER  DOES  NOT  MATCH  THE 
NTJMBEF  Rt'^RTFVFD  IN  THE  GFTHOLD 

'^his  error  only  applies  to  the  UPDATE  command. 

16)  INSUFFICIENT  SPACF  R  INSERTIONS  --  NO  TUPLES  INSERTED 

The  requested  insertions  would  overflow  the  tuple  guota 
for  the  rela-^ion. 

17)  USFR  NOT  PERMITTED  TO  PFPEOPM  A  <function  name> 

IS)  UPDIiTE  WAS  NO-^  ^EFCFEED  BY  A  HOLD  OR  THE  HOLD  WAS  DROPPED 

19)  DATA  BASE  WAS  ALPEADY  BEING  HELD  FOR  YOU  —  HOLD  DROPPED 
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The  user  has  attempted  to  execute  some  command  other 
than  nPDATE  or  RELEASE  while  he  had  a  hold  on  the  data  base. 
The  effect  is  the  same  as  that  of  a  PELEA.SE. 

20)  RELEASE  WAS  NOT  PRECEDED  BY  A  HOLD  OF  THE  HOLD  WAS  DR0PT»ED 
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Cha£t er_4 

§l£ll£i:Ure_corama  nd 

’=’DBS  provides  an  additional  command  that  loos  not  retrieve 
information  from  the  data  base,  but  performs  an  ancillary  service 
for  the  user.  This  command  can  be  used  with  the  hierarchical  or 
relational  subsystem.  t  is 

.STPnC'^TIFE  •<data  base  name>' 

The  logical  structure  of  the  data  base  is  retrieved  and 
listed.  The  logical  structure  depends  on  whether  the  user  is 
currently  accessing  his  data  base  hierarchically  or  rela t iona lly. 
The  format  of  the  output  is  the  same  as  for  that  of  the  data 
definition. 

Infprmation  Format 

There  is  a  well  defined  format  for  information  being  entered 
into  the  da-t-a  base.  Users  must  be  aware  of  the  conventians  used; 
otherwise,  the  system  will  consistently  respond  with  error 
messa  ges. 

There  are  two  levels  of  formatting  with  which  usars  should 
become  familiar.  The  first  -  user  level  format  -  is  read  by 
and  converted  to  the  second  -  internal  EDBS  format  -  which  is  the 
actual  representation  of  the  da^a  in  the  physical  files  on  which 
the  lata  base  information  is  stored. 
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TTser  Level  Format 

A.n  FDP.S  variable  is  any  sequence  of  valid  aluhanumerics 
beginning  with  a  letter.  Valid  alphanumeric s  are 
*  ABC.  ,  .  XYZC  1 .  ,  .  ,  with  the  period  for  joining  demains  to 

relations.  No  underscored  letters  are  allowed. 

EBBS  accepts  three  different  data  formats.  They  are: 
i)  Dates 

Dates  must  have  the  following  format: 


<mor  t  hXa 

single  blankXnumbe 

rXa 

single  blankXyear> 

where  <month> 

is  the 

name  of  a 

month 

or  a  short  form 

fora 

month.  Thus  <month>  can 

be  any  of; 

JANUARY, 

JAN 

FEBRUARY, 

FEB 

MARCH, 

MAP 

A^RIL, 

APR 

NAY, 

NAY 

JUNE, 

J[JN 

JULY, 

JUL 

AUGUST , 

AUG 

SEPTEMBER , 

SEPT 

OCTOBER, 

OCT 

NOVFKBER, 

NOV 

DECEMBER , 

DFC 

The  expression 

<number>  is  any 

Of  1, 

2,  3,  ...  ,  up 

to  the 

last  day  in  <month>. 

The  expression 

<yea  r> 

is  a  posit 

ive  unsigned  integer 

giving 

the  exact  year 

(no  short 

forms  or 

contractions)  , 

F xam pies  of  valid  dates  are: 

JAN  1  1963 


APFTL  29  1920 
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ii)  Niimb<=rs 

lumbers  accepted  hy  FPBS  are  in  the  form  of  roal  numbers: 

digits  plus  decimal  point  plus  optional  sign. 

A.11  numbers  have  a  length  associated  with  them  which  is 
calculated  by  adding  the  number  of  digits,  plus  1  if  there  is 
a  sign,  plus  another  1  if  there  is  a  decimal  point. 

Note : 

In  convertirg  from  user  level  to  internal  FDB3  format  a 
number  may  be  truncated  to  allow  it  to  fit  into  the  space 
reserved  for  it.  In  truncating  a  number,  only  the  fractional 
part  of  a  number  will  be  truncated.  The  whole  (integer)  part 
of  a  number  is  never  truncated.  If  the  whole  part  of  a  number 
will  not  fit  into  the  space  reserved  for  that  number,  an 
error  message  will  be  produced. 

iii)  Strings 

\  string  is  a  sequence  of  alphanumeric  characters.  Its 
length  is  defined  to  be  the  number  of  characters  in  the 
string. 

Internal  FDPS  Format 

The  internal  representation  of  th’^^  information  is  explained 
here,  References  are  made  to  PDL  (Data  Definition  Language)  which 
is  explained  later  in  this  chapter. 
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a)  "^ates 


Dates  are 

Stored 

as  an  8  character  long  string 

with 

th  9 

following 

format ; 

DDMWYYYY  , 

DD 

the 

day;  single  number  days 

are  prec 

e  ded 

by  a 

0, 

e.g..  Cl. 

NM 

th  e 

month;  single  number 

mon  ths 

are 

also 

pr  9 

ceded  by  a  0. 

YYYY 

-  the 

year;  this  must  be  the 

complete 

year 

(no 

short  forms).. 


b)  Numbers 

Numbers  occupy  the  number  of  characters  specified  in  the  DDL 
that  created  the  data  base.  Numbers  are  stored  right 
justified  ir  rhe  field  with  preceeding  zeros  if  necessary. 
Each  digit  (including  decimal  point  and  optional  sign) 
occupies  ore  charac-*:er  in  the  string.  The  optional  sign  is 
the  leftmost  character  in  the  string. 


c)  Strings 

Strings  occupy  the  number  of  characters  specified  in  the  DDL 
that  created  the  data  base.  Strings  are  stored  left  justified 
in  the  field  and  padded  with  blanks  on  the  right  if 
necessary .  Note  that  in  order  for  a  string  to  mat oh  on  a 
search,  it  must  he  specified  exactly  as  first  entered  into 
the  data  base,  except  for  trailing  blanks. 


I:  initio  H-Ldn^ua^e (DDLj_ 


"'h'^  data  definition  describes  all  units  of  logical  data  by 
specifying  type  and  size  of  the  units,  as  well  as  the  logical 
relationships  that  exist  between  them.  The  information  obtained 
from  the  DDL  is  used  to  map  the  logical  structure  of  the  data 
onto  physical  storage. 

^or  information  about  the  FPBS  data  base  definition  facility 
and  other  data  base  administration  utilities  see  the  ^iiicational 
System  Data  Base  Subsystem  ManijaT_, 

Mi2£2^2lli2al_pat a_pef  init  ion 

The  first  line  in  the  DDL  specifies  the  name  of  the  data  base 
and  what  type  it  is,  either  hierarchical  or  relational.  For 
a  hierarchical  data  base  it  is: 

Dh*TA  BASF  <data  base  name>  HIERARCHICAL 

An  occurrence  of 

SEGiMENT  <segment  Rame>  <number> 

defines  a  new  segment  type  with  segment  name  <segment  name>. 
In  the  SEGMENT  sta-^ement,  <nuraber>  specifies  ■'•he  maximum 
number  of  segments  of  that  segment  type  which  may  occur  as 
sons  under  any  paren-*-  segment. 

In  order  to  close  the  scope  of  a  logical  segment. 


END  <segment  name> 
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is  used,  where  <segment  name>  is  the  same  as  in  the 
corresponding  SFSMENT  statement,  occurrence  of 

SEGMENT  <segment  name_1>  .  ,  , 

SEGMENT  <segment  name_2>  .  .  . 

ENP  <seg[nen'*‘  name_2> 

ENP  <seginent  name_1> 

is  used  to  imply  that  <segment  name_2>  is  a  son  of  <segmen+: 
name_ 1>. 

Fields  within  a  segment  are  defined  by 

FIFLP  <^ield  name>,  <type>  {  :  <index  part>} 

The  expression  <type>  is  to  be  replaced  by  one  of: 

1)  DATE, 

2)  NUMERIC  <lergth>,  where  <length>  is  the  length  of 
the  numeric  field. 

3)  STRING  <length>,  where  <length>  is  ths  maximum 
length  of  the  string 

The  expression  <index  part>  in  the  FIELD  statement  is  either: 
1)  KEY  or 


2) 


INDEXED 
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KFY  desiqnates  the  field  wi^h  which  it  is  found  tD  be  a  key 
field  of  the  segment.  If  INDEXED  appears,  then  that;  field  is 
to  be  an  indexed  field  (i.e.,  is  to  have  an  inverted  list 
maintained  for  it).  Key  fields  are  implicitly  indexed. 

There  may  be  arbitrarily  many  fields  in  each  segment. 

The  end  of  the  data  definition  is  given  by 

ENT  <data  base  name> 

where  <data  base  name>  must  be  the  same  as  in  the  DATA.  BASE 
statement , 

Bases 

Hierarchical  data  bas^s  are: 

1)  COMPANY 

2)  COFPOP.ATE 

DATA  BASE  COJ^PANY  HIEPAFCHICAL 
SEGMENT  EMPLOYEE  10 

FIELD  manNO,  NDMEPTC  5  : 

FIELD  NAME,  STRING  20 
FIELD  BIP.THDATE,  DATE 
SFGMFN'T’  JOBHISTOPY  5 

FIELD  JOBDATE,  DATE 
■^IFLD  TITLE,  STRING 


KEY 


KEY 


10 
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SEGMENT  SA.LAEYHTSTOHY  2 

FIELD  SA.LAEYDATE,  DATE  :  ^<EY 
FIELD  SALARY,  NUMERIC  6  :  INDEXED 
END  SALARYHISTORY 
END  JOBHISTOPY 
SEGMENT  CHILDREN  5 

FIELD  CHILDNAME,  STRING  10  :  KEY 
FIELD  BIRTHYEAR,  NUMERIC  4 
END  CHILDREN 
END  EMPLOYEE 
END  COMPANY 

DATA  BASE  CORPORATE  HIERARCHICAL 

SEGMENT  DEPARTMENT  7 

FIELD  NAME,  STRING  15  :  KEY 

SEGMENT  EMPLOYEE  20 

FIELD  NUMBER,  NUMERIC  9  :  KEY 
FIELD  NAME,  STRING  20 
T^IELD  SALARY,  NUMERIC  7  :  INDEXED 
FIELD  MANAGEPNUMBEP,  NUMERIC  4  :  INDEXED 


END  EMPLOYEE 


SFGKFNT  PAFT  15 
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FIELD  PAFTNAFE,  STPTNG  20  :  KEY 

SEGMENT  SUPPLIER  3 

FIELD  SUPPLIERNAME,  STRING  20  ;  KEY 
FIELD  VOLUME,  NUMERIC  7  :  INDEXED 
END  SUPPLIFP, 

END  PAF'^' 

T^ND  DEPAPTMENT 
END  CORPORATE 


Relational  Data  Definition 

The  relational  data  structure  is  established  by 
DA-^A  BASE  <data  base  name>  RELATIONAL 

Each  relation  is  defined  by 

RELATION  <rfclation  name>  <total  Rumber> 

where  <total  nutnher>  is  a  positive  integer  specifying  the 
total  maximum  number  of  tuples  allowed  for  that  relation, 

A  relation  may  not  lie  within  another  relation. 

Each  relation  consists  of  domains  declared  by 

DOMAIN  <domain  name>,  <type>  {  :  <index  part>} 

where  <type>  and  <index  part>  are  the  same  as  for  the 
hierarchical  data  definition. 


-71 


Pelational  flata  bases  are; 


1)  SCHOOL 


DAT^  BASE  SCHOOL  P ELAT TONAL 

RELATION-  STUEFVT  6G 

DOMAIN  MHMBEF,  NDMERIC  9  : 

DOMAIN  NAME,  STRING  20 
DOMAIN  BIRTHDATE,  DATE 
END  STUDENT 

RELATION  CLASS  15 

DOMAIN  NUMBER,  NUMERIC  4  :  KEY 
DOMAIN  SUBJECT,  STRING  10  :  INDEXED 
DOMAIN  LEVEL,  NUMERIC  2  :  INDEXED 
DOMAIN  TEACHER,  STRING  20 
END  CLASS 

RELATION  COURSE  120 

DOMAIN  STUDENTNUMBEP ,  NUMERIC  9  :  KEY 
DOMAIN  CIASSNUMBER,  NUMERIC  4  :  KEY 
DOMAIN  MARK,  NUMERIC  3  :  INDEXED 
ENn  COURSE 


END  SCHOOL 
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Pela-^ioral  View  of  Hierarchies 

In  order  to  convert  the  definition  of  a  hierarchical  data 
base  to  that  of  a  relational  form,  follow  these  steps; 

1)  A.11  segment  names  in  the  hierarchical  definition  become 
relation  names.  The  maximum  instances  of  a  relation  are  found 
by  taking  the  firoduct  of  the  maximum  instances  of  the  direct 
ancestors  of  the  the  segment  type  up  to  and  including  the 
root  segment  type. 

2)  The  domains  of  a  relation  are  found  by  taking  all  the  fields 
within  the  corresponding  segment  type  plus  all  key  fields  of 
the  direc-^  ancestors  of  that  segment  type  up  to  and  including 
the  root  segment  type, 

\11  key  fields  mapping  into  a  relation  form  the  candidate  key 
for  the  relation, 

4)  Indexed  fields  become  indexed  domains. 

Remember  that  only  retrieval  commands  are  available  for  these 
data  bases. 

Data  bases  structured  for  relational  retrievals  are: 

1)  COMPANY 


2) 


CORT’CRATE 
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DAT 7^.  3AS^  COMPANY  RELATIONAL 

RFLATION  employee  10 

DOMAIN  MANNO,  NUMERIC  5  :  KEY 
DOMAIN  NAME,  STRING  20 
DOMAIN  BIRTRDATE,  DATE 
END  EMPLOYEE 

RELATION  JOBHISTORY  50 

DOMAIN  MANNO,  NUMERIC  5  ;  KEY 
DOMAIN  JO  ED ATE,  DATE  :  KEY 
DOMAIN  TITLE,  STRING  10 
END  JOBHISTORY 

RELATION  SALARYHISTORY  100 

DOMAIN  MANNO,  NUMERIC  5  :  KEY 
DOMAIN  JOEDATE,  DATE  :  KEY 
DOMAIN  SALAPYDATF,  DATE  :  KEY 
DOMAIN  SALARY,  NUMERIC  5  :  INDEXED 
END  SALARYHISTORY 

RELATION  CHILDREN  50 

DOMAIN  MANNO,  NUMERIC  5  :  KEY 
DOMAIN  CHTLDNAME,  STRING  10  :  KEY 
DOMAIN  BI^THYEAR,  NUMERIC  4 
END  CHILDREN 


END  COMPANY 
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uples  are  of  the 

form: 

relation  name 

doma in 

names 

EMPLOYEE 

(MAN  NO, 

NAME,  BIRTHDATE) 

JORHISTORY 

(MANNO, 

J03DA;^E,  TITLE) 

SALARYHI STORY 

(MAN  NO, 

JOBDATE.  SALARYDATE, 

CHILDREN  ' 

(MANNO, 

C  H I L  D  N A  M  E  ,  B I R  TH  Y E  AH ) 

date  key  domains 

are  underl 

ined . 

Finding  the  relational  definition  for  CORPOB\TE  is  laft  as  an 
exercise  for  the  reader. 

Suggested 


A.  number  of  exercises  are  presented  here  for  use  with  EDBS. 
Most  of  them  involve  programming  with  EDBS.  The  first  set  of 
programming  exercises  use  •‘■he  hierarchical  and  ralational 
subsystems  in  fairly  elementary  ways.  The  next  set  consists  of 
games  which  require  the  players  to  interact  with  the  data  base  in 
more  complex  ways.  The  exercises  should  give  the  usars  some 
expertise  in  the  use  of  data  base  systems  and  in  the  use  of  EDBS 
in  particular. 
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Exercise  Set  I 

The  first  set  of  exercises  uses  a  data  base  for  a  small 

company.  This  corporate  data  base  contains  information  about  the 

inventory,  suppliers,  departments  and  employees  of  the  company. 
The  company  is  divided  into  several  departments.  Each  department 
has  a  number  of  employees  and  uses  a  number  of  parts.  Each 

department  gets  its  parts  from  one  or  more  different  suppliers. 

The  corporate  data  base  has  been  defined  hierarchically  to 
reflect  this  structure  of  the  company.  The  data  base  iafinition 
in  the  EDBS  PDL  follows. 

DATA  BASE  COF.nopATF  HIERARCHICAL 

SEGMENT  DEPARTMENT  7 

FIELD  NAME,  STRING  15  :  KEY 

SEGMENT  EMPLOYEE  20 

FIELD  NUMBER,  NUMERIC  9  :  KEY 
FIFLD  NAME,  STRING  20 
FIELD  SALARY,  NUMERIC  7  :  INDEXED 
FIELD  MANAGEPNUMBER,  NUMERIC  4  :  INDEXED 
END  EMPLOYEE 
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SEGMENT  PAPT  15 

FIELD  PARTNAME,  STRING  20  :  KEY 

SEGMENT  SITPPLIFP  3 

FIELD  SUPPLIE3NAME,  STRING  20  ;  KEY 
FIELD  VOLUME,  NUMERIC  7  :  INDEXED 
END  SUPPLIER 

END  PART  ' 

END  DEPARTMENT 

END  CORPORATT^ 

Ex.  1)  The  COPPOPATE  data  base  can  be  accessed  either 
hierarchically  or  relationally.  Using  the  EDPS  DDL  syntax, 
give  the  (definition  of  the  CORPORATE  data  base  as  it  would 
appear  to  a  relational  user. 

Ex.  2)  For  each  of  the  following  queries,  write  ona  program 
which  answers  the  query  using  the  hierarchical  system  and 
another  program  which  answers  the  qu^ry  using  the  relational 
system. 

2a)  Find  the  nam-=>s  of  all  companies  who  supply  parts  to 
department  w.  (W  is  a  parameter  which  may  range 
over  the  department  names.) 

2b)  Find  the  names  of  all  employees  who  work  for  a 
department  which  is  supplied  by  company  X.  (X  is  a 
parameter  --  it  may  range  over  all  supplier  names.) 

The  next  •'■hree  exercises  in  this  set  involve  sora^  simple  uses 


of  the  modification  commands 
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Ex.  3)  Write  ?  program  which  inserts  a  new  2J1PL0YEF  segment 

into  the  data  base.  Test  this  program  by  inserting  a  new 
EMPLOYEE  segment  into  the  department  named  'New' ,  Use  your 
own  student  number  in  the  NUMBER  field  of  the  EMPLOYEE 
segment.  Any  suitable  values  may  be  used  for  the  other 
fields.  Retrieve  and  print  out  the  value  of  the  new  segment. 

Ex.  4)  Write  a  program  which  increments  the  value  of  a  SALARY 

field  of  the  EMPLOYEE  segment.  Use  this  program  to 
increment,  by  1C,  the  value  of  SALARY  field  of  the  EMPLOYEE 
segment  that  was  inserted  in  Ex.  3.  Retrieve  and  print  out 
the  value  of  the  new  segment. 

Ex.  5)  Write  a  program  which  deletes  an  EMPLOYEE  segment.  Use 
this  program  to  delete  the  segment  inserted  in  ^x.  3.  Attempt 
to  retrieve  the  segment  just  deleted.  A  null  value  in  the 
buffer  and  a  STATUS  value  equal  to  3  will  indicate  that  the 
deletion  was  successful. 

This  set  of  exercises  uses  a  small  data  base  for  a  school. 
The  data  base  holds  information  about  the  students,  their  marks 
and  the  classes  aiven  in  the  school.  The  data  base  uses  the  EDBS 
relational  oraanization  and  canno'*’  be  accessed  hierarchically. 
The  data  base  definition  follows. 
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DATA  BASE  SCHOOL  PFLATTONAL 

RFLATTON  STUDENT  60 

DOMAIN  UUMBEP,  NUMERIC  9  :  KEY 
DOMAIN  NAME,  STRING  20 
DOMAIN  BIRTHDATE,  DATE 

END  STUDENT 

RELATION  CLASS  15 

DOMAIN  NUMBER,  NUMERIC  4  :  KEY 
DOMAIN  SUBJECT,  STRING  10  :  INDEXED 
DOMAIN  LEVEL,  NUMERIC  2  :  INDEXED 
DOMAIN  TEACHER,  STRING  20 

END  CLASS 

RELATION  COURSE  120 

DOMAIN  S'^DDENTNUMBEF,  NUMERIC  9  :  KEY 
POV?..iM  CLASSNUMBER,  NUMERIC  4  ;  KEY 
DOMAIN  MARK,  MUMEPIC  3  :  INDEXED 

■^ND  COURSE 

END  SCHOOL 

The  STUDENT  relation  is  self-explanatorv.  Each  studeot  is 
uniquely  ider.tifi«^d  by  a  nine  digit  positive  integer.  There  is 
one  STUDENT  tuple  for  each  student  in  the  school. 

Eor  each  class  given  in  the  school  there  is  one  CLASS  tuple 
in  the  data  base.  Each  class  is  identified  by  a  four  digit 
positive  integer.  The  classes  are  each  taught  a  subject  at  a 
particular  level.  The  level  is  denoted  by  a  two  digit  positive 


integer.  The  COUPS^  relation  records  the  students  in  each  class 

and  the  marks  received.  Each  mark  is  an  integer  between  0  and 

100.  One  student  may  be  in  several  classes. 

Ex.  1)  Is  the  SCHOOL  data  base  in  second  normal  form?  What 
assumptions  are  necessary  to  ensure  that  the  data  base  is  in 
third  normal  form? 

Ex.  2)  Write  a  program  which  finds  the  names  of  all  the 
teacher-%  teaching  subject  X. 

Ex.  3)  Write  a  program  which  finds  the  average  mark  for  each  of 
the  subjects. 

Ex.  4)  Write  a  program  which  inserts  a  new  STFJDENT  tuple  and 

COHRSE  tuples  for  that  student  into  the  data  base. 
Demonstrate  the  program  by  inserting  one  new  STUDENT  tuple 
and  three  COURSE  tuples  for  this  student.  Use  your  own 

student  number  in  this  new  STUDENT  tuple  and  select  courses 
already  in  the  data  base  to  use  in  the  new  COURSE  tuples. 
Retrieve  and  print  out  these  new  tuples. 

Ex.  5)  Write  a  program  which  changes  the  MARK  item  of  a  COURSE 
tuple  for  student  number  X  and  class  number  Y,  Demonstrats 
this  program  by  changing  ■'■he  MARK  item  of  one  of  the  COURSE 
tuples  in sert ed  in  .  4  .  Retrieve  and  print,  out  th i s  t  j  pie. 

Ex.  6)  Write  a  proaram  which  deletes  all  mention  of  student 

number  S  from  the  data  base.  Demonstrate  this  program  by 
deleting  the  tuples  inserted  in  Ex, 


Chagt er_5 

The  two  cfaraps  discussed  in  this  chapter  are  designed  to  help 
you  understand  data  base  management  concepts  and  uses.  The  only 
way  they  can  assist  you,  though,  is  by  actually  playing  them. 

The  games  simulate  a  real  world  environment.  In  the  first  - 
Stock  f'arket  Game  -  the  players  buy  and  sell  shares  in  various 
imaginary  companies.  Tn  the  second  -  Production  Game  -  each 
player  owns  a  fictitious  company  and  must  secure  enough  supplies 
in  order  to  make  finished  products  which  can  then  be  bought  and 
sold . 


Unlike  "board”  games  where  2  to  6  people  sit  around  a  playing 
board  for  a  few  hours  at  a  time,  these  games  involve  the  entire 
class  and  are  played  over  a  period  of  a  few  weeks,  meaning  that 
you  can  play  intermittently  a^  your  own  convenience.  The  more  you 
participate  and  get  involved,  the  more  fun  the  games  will  become, 
and  the  sneakier  and  craftier  you  are,  the  more  assets  you  will 
end  up  with  at  the  end. 

A  monitor  or  referee  has  been  built  into  the  Ems  system  to 
oversee  and  validate  all  transactions  and  to  enforce  the  rules. 

The  actual  state  of  the  game  (offers,  asks,  quantities, 
prices,  etc.)  is  kept  in  the  data  base,  which  all  players  can 
interrogate  at  any  time  (rules  permitting).  The  format  of  the 
data  within  the  data  base  is  discussed  with  each  of  the  games. 
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Participation  in  the  games  involves  making  modi  f  icatio.i  s  to  the 
data  base. 

Of  course,  all  interrogations  and  modifications  are  performed 
with  the  available  EDPS  commands  as  described  in  chapters  2  and  3 
of  this  manual. 

What  differentiates  these  games  from  standard  programming 
exercises  is  that  the  games  themselves  are  not  concernel  with  the 
DBMS  (Data  Base  Management  System)  or  information  management,  but 
with  competitive  play  between  players,  EDRS  is  just  a  tool 
needed  to  play  the  game.  The  enjoyment  of  the  exercise  comes  from 
the  competition  in  the  game. 
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STOCK  MARKF;^ 


In  stock  market  game  the  players  buy  and  sell  shares  in 
various  imaginary  companies,  A  player  starts  out  witi  $20,000 
and  no  stocks  in  his  portfolio.  He  can  then  make  money  by 
receiving  dividends  or  by  selling  stocks  for  more  than  he  paid 
for  them.  The  object  is  to  accumulate  as  valuable  a  portfolio  as 


possible . 

At 

the  end  of  the 

g  ame 

each 

portfolio  will  be 

evaluated 

by 

using  the  share 

price 

of 

the  last  sale  of  a 

compa  ny ' s 

stock 

as  the  value  of  t 

he  company's 

shares . 

When  a  person  wants  to  buy  or  sell  shares  he  first  sees  if 
there  is  an  offer  which  is  acceptable  in  price  and  guantity.  If 
so  he  accepts  that  offer,  taking  the  whole  quantity  of  the  offer. 
Otherwise,  he  makes  a  bid,  an  offer  to  purchase,  or  an  ask,  an 
offer  to  sell,  for  a  specific  price  per  share  and  quantity  and 
waits  for  someon*^-  to  accept  his  offer.  The  playar  must  decide 
what  is  the  best  price  he  can  aet  and  what  quantities  will  he 
acceptable  to  the  other  players.  He  may  decide  to  split  his 
offer  into  several  smaller  offers,  perhaps  with  different  prices. 

A  player  may  base  his  strategy  on  several  sources  of 
information.  He  may  see  the  last  price  of  each  stock  and  all  the 
current  bids  and  asks.  He  may  also  look  at  the  number  af  shares 
outstanding  and  the  dividend  notices  for  the  companies.  3f 
course,  he  may  also  look  at  his  own  portfolio.  However,  he  may 
not  look  at  the  state  of  any  other  player's  portfolio. 

The  game  administrator  can  offer  for  sale  any  shares  to 
artificially  inflate  or  deflate  the  market. 
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Xil£  2^1^  2ase 

This  game  uses  a  hierarchic  (lata  base  with  one  record  per 
company.  The  data  base  is  described  using  the  EDBS  DDL  syntax: 
DATA.  BASE  S'^OCKMAFKET  HIEPAPCHICAL 
SEGMENT  COMPANY 


FIELD  NAME,  STPING  20  :  KEY 
FIELD  OUTSTANDING,  NUMERIC  5 
FIELD  PPICE,  NUMERIC  6 


SEGMENT 

BID 

r  - —  " 

FIELD 

TIME,  NUMERIC  14  : 

KEY 

FIELD 

PLAYER,  NUMERIC  9 

:  KEY 

FIELD 

ODANTITY,  NUMERIC 

5 

FIELn 

PPICE,  NUMERIC  6 

END  BID 

SEGMENT 

ASK 

FIELD 

TIME,  NUMERIC  14  : 

KEY 

FIELD 

PLAYER,  NUMERIC  9 

:  KEY 

FIELD 

QUANTITY,  NUMERIC 

5 

FIELD 

PRICE,  NUMERIC  6 

END  ASK 


-84 


S^GMFNT  SHAREHOLDER 

FIELD  PLAYER,  NUMERIC  9  :  KEY 
FIELD  QUANTITY,  NUMERIC  5 
FIELD  PAID,  NUMERIC  8 
FIELD  RECEIVED,  NUMERIC  8 
FIELD  LASTDIVIDEND,  NUMERIC  14 

EN^  SHAREHOLDER 

SEGMENT  PURCHASE 

FIELD  PLAYER,  NUMERIC  9  :  KEY 
field  TIME,  NUMERIC  14  :  KEY 
FIELD  QUANTITY,  NUMERIC  5 
FIELD  PRICE,  NUMERIC  6 

END  PURCHASE 

SFGMFN'^  SALE 

’^IFLD  PLAYER,  NUMERIC  9  :  KEY 
FIELD  TIME,  NUMERIC  14  :  KEY 
FIELD  QUANTITY,  NUMERIC  5 
FIELD  PRICE,  NUMFRIC  6 

END  sale 

SEGMENT  DIVIDENDNOTICF 

FIELD  TIME,  NUMERIC  14  :  KEY 
EIFLD  AMOUNT,  NUMERIC  4 

END  DIVIDENDNOTICE 
END  COMPANY 


END  STOCKMAPKFT 


Th^  COMPANY,  BID,  ASK  ar.'l  PI VTDBNDNOTICE  segments  are  fairly 
self-explanatory.  The  COMPANY  segment  gives  the  company  name, 
the  number  of  shares  outstanding,  and  the  last  price  of  the 
company's  stock.  The  BID  and  A.SK  segments  give  the  players 
making  bids  and  asks  and  the  prices  per  share  anl  quantities  of 
the  offers.  '^he  PIVI DENDNOTICE  segments  record  the  amounts  of 
the  dividends  and  the  time  the  dividend  is  payable. 

The  SHAPEHOIDER,  PHRCHASE  and  SALE  segments  are  more 
difficult.  The  information  about  a  player's  portfolio  is  spread 
among  the  various  company  records.  Within  a  company  record  there 
is  one  SHAREKOLDEP  segment  for  each  player  who  ever  was  a 
shareholder  in  the  company.  The  segment  records  the  number  of 
shares  he  currently  holds,  the  total  price  he  has  paid  for  all 
his  purchases  of  the  company's  stock,  the  total  amount  he  has 
received  from  the  company’s  dividends  and  the  company's  stock, 
and  the  time  the  las^  dividend  he  received  was  payable.  The 
SHA.PEHOLDER  segment  is  confidential:  a  player  may  not  examine 
another  player's  SHAPEHnLDFP  segments.  However  when  a  player 
effects  a  sale  or  purchase  he  must  notify  the  other  party.  This 
is  done  by  inserting  a  PUPCHASE  or  SALE  segment  with  the  other 
player's  number  and  the  time,  quantity  and  price  per  share  of  the 
trade.  Each  player  must  do  periodic  housekeeping  to  collect  his 
purchase  and  sale  notices  and  update  his  SHAREHOLDER  segments. 

Players  are  idf^rtified  by  their  student  numbers.  All  tim^^s 
are  in  sixtieths  of  a  s-^cord  from  midnight  ''^eb.  29/March  1  196C. 
All  other  identifying  names  and  numbers  in  the  data  base  are 
assigned  by  the  game  administrator. 
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Pules 

1)  Pach  player  starts  out  with  $20,000  and  no  shares. 

2)  Initially  all  shares  are  held  by  the  game  administrator  and 
will  be  sold  in  lots  of  approximately  $500,  with  each  share 
priced  at  about  twenty  times  the  first  dividend. 

3)  Each  player  must  make  at  least  ten  and  at  most  twanty  five 
t ransa’ctions  during  the  game. 

4)  Shares  are  sold  by  accepting  a  bid  or  posting  an  ask  and 

waiting  for  its  acceptance.  There  are  the  f  o flowing 

restrictions: 

a)  A  player  may  not  sell  shares  he  does  not  own. 

b)  A  bid  is  accepted  by: 

i)  Deleting  the  bid  from  the  data  base. 

ii)  Inserting  a  PDPCHASE  segment  giving  the  purchaser's 
number  and  the  time,  price  per  share  and  quantity 
of  the  trade  under  the  company’s  COMPANY  segment. 

iii)  Dpdating  the  PPICE  field  of  the  COMPANY  segment 
with  the  price  per  share  of  the  trade. 

iv)  Updating  the  seller's  own  SHAREHOLDER  segment. 

c)  If  there  are  two  or  more  acceptable  bids  for  the  same 
price  and  quantity  the  earliest  must  be  accepted  before 
the  res*" . 

d)  ask  is  posted  by  inserting  an  ASK  segment  with  the 
player  number  and  the  time,  price  per  share  and  quantity 


of  the  ask. 
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e)  A  player  may  not  post  an  ask  if  there  is  already  an 
outstanding  bid  for  the  same  price  and  quantity  as  the 
ask . 

5)  Shares  are  bought  by  accepting  an  ask  or  by  posting  a  bid  and 
waiting  for  its  acceptance.  There  are  the  following 
restrict i ons : 

a)  h  player  may  not  spend  more  money  than  he  has. 

b)  An  ask  is  accepted  by: 

i)  Deleting  the  ask  from  the  data  base. 

ii)  Inserting  a  SALE  segment  giving  the  seller’s  nimber 
and  the  time,  price  per  share  and  the  quantity  of 
the  trade  under  the  C0?1PANY  segment. 

iii)  ripdating  the  PRICE  field  of  the  COKPANY  segment 
with  the  price  per  share  of  the  trade. 

iv)  Upda.*-ing  the  buyer’s  own  SHAREHOLDER  segment. 

c)  If  there  are  two  or  more  acceptable  bids  then  the 
earliest  must  be  accepted  before  the  rest. 

d)  A.  hid  is  made  by  inserting  a  BID  segment  with  the 
bidder’s  number  and  the  time,  price  per  share  and 
quantity  of  the  bid  under  the  COMPANY  segment  of  the 
company  whose  stock  is  being  bid  on. 

e)  A.  player  may  not  make  a  hid  if  there  is  already  an 
outstanding  ask  for  the  same  price  and  quantity  as  the 
bid. 

6)  A  Dlay<=^r  must  periodically  collect  any  sale  or  purchase 
notices  with  his  number  on  them  and  update  his  SHAREHOLDER 
segments.  A  sale  notice  is  collected  by  deleting  the  SALE 


segmpnt,  subtracting  the  guantity  soli  from  the  player’s 
QUANTITY  field  of  the  SHAREHOLDER  segment  for  that  company 
and  adding  the  total  price  of  the  trade  to  the  RECEIVED  field 
of  his  SHf-REFOLDEF  segment,  A  purchase  notice  is  collected  by 
deleting  the  PUFTHASE  segment,  inserting  a  SHAREHOLDER 
segment  if  necessary,  adding  the  guantity  bought  to  the 
QUANTITY  field  of  the  SHAREHOLDER  segment  for  that  company 
and  adding  the  total  price  to  the  PAID  field  of  the 
SHAPE HOLDER  segment, 

7)  Due  to  system  limits  on  the  number  of  segments  of  a 
particular  type,  the  numbers  of  BID,  A.SK  SALE  and  PURCHASE 
segments  must  be  limited.  A.t  any  one  time  a  player  may  have 
at  most  a  total  of  five  BID  and  PURCHASE  segments  and  a  total 
of  five  ASK  and  SALE  segments  under  any  company. 

8)  A  player  may  delete  or  modify  a  BID  or  ASK  segment  with  his 
number  on  it.  Otherwise  BID  and  /ASK  segments  may  not  be 
modified  and  may  only  be  deleted  to  accept  the  bid  or  ask. 

His  ’  game  administrator  announces  dividends  by 

inseri-ing  DIVJDEN DNOTICE  segments.  A  player  may  claim  a 
divider.'^  for  *^ach  share  he  owned  at  the  +-.ime  the  dividend  was 
payable.  He  receives  the  dividend  by  adding  his  total 
dividend  (th<=‘  amount  in  the  dividend  notice  times  the  number 
of  shares  he  owner  in  the  company  when  the  diviiend  was 
payable^  to  the  RECEIVED  field  of  his  SHAREHOLDER  ssgment  for 
that  company. 
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11)  The  penalty  for  violating 
3,  is  $10C  plus  any  gai 
Penalties  will  be  assessed 
administrator  may  correct  an 
the  game.  The  penalty  for  v 
number  of  transactions  by  wh 
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PPODHCTION  GAME 


In  this  game  each  player  runs  his  own  company.  Each  company 
has  several  projects,  each  requiring  several  different  supplies 
and  producing  several  different  products.  Each  project  has  a 
deadline  by  which  it  must  be  completed,  or  the  company  will  face 
a  penalty. 

The  players  each  start  out  with  $20, COO  and  no  inventory. 
The  game  supervisor  initially  offers  for  sale  enough  of  the  goods 
for  the  companies  to  start  some  of  their  projects.  From  then  on 
the  players  may  buy  or  sell  any  of  the  goods  on  an  open  market. 
Since  each  product  will  be  used  by  several  different  corapenies 
and  produced  by  several  companies,  rhe  market  should  ha  fairly 
lively. 

The  object  of  the  game  is  to  have  the  most  assets  at  the  end 
of  the  game.  Cash  will  be  valued  at  -^ace  value.  Inventory  will 
be  valued  usin(i  a  weighted  average  of  the  prices  pail  for  the 
goods  during  the  game.  The  weighting  is  used  to  giv(=  the  latest 
prices  the  most  importance  in  the  valuation  of  the  goods.  There 
will  be  an  additional  penalty  of  $1C0^  for  each  project  not 
finished  at  ^he  end  of  the  game. 

The  players  will  have  access  to  a  good  deal  of  information. 
•A  history  of  all  the  transactions,  -^he  requiremen-^s  an  i  products 
of  the  various  projects,  the  cash  and  inventory  positions  of  all 
the  players  and  records  of  all  completed  projects  are  all  public 
information,  '^he  only  private  information  is  tha  project 
deadlines;  a  player  will  only  know  his  deadlines.  Eaoli  player 
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will 

ha  ve 

to 

use 

this 

in 

format  ion 

t  o 

try 

to  out- 

■guess  his 

opponents. 

He 

must  t 

ime 

his 

purchases 

to 

buy  the 

goods 

he  needs 

at  as 

low  a 

price  as 

poss 

ible 

and.  time 

hi  s 

sales 

to  get 

as  high  a 

price  as  possible.  In  addition,  a  player  may  try  to  speculate  in 
goois  which  he  does  not  use  or  produce. 

The  production  game  uses  a  relational  data  base  to  store  its 
information.  The  data  base  definition  follows: 

data  base  PP0DGA.P1F  relational 

relation  OFFFP 

domain  string  10:  key 

domain  SUPPLIFP,  numeric  9:  key 
domain  PPICE,  numeric  B:  key 
domain  QUANTITY,  numeric  6 

end  OFFFP 

relation  TPANSAC^IOU 

domain  PAP"',  string  1C:  key 
domain  SFILFP,  numeric  :  key 
domain  PURCFIASEP,  numeric  9:  key 
domain  '^THF,  numeric  1  :  key 
domain  QUANTITY,  numeric  6 
domain  PRICE,  numeric  8 


end  TRANSACTION 
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relation  COMPLETION 

domain  COMPANY,  numeric  9:  key 
domain  PROJECT,  string  10:  key 
domain  numeric  14 

end  COMPLETION 

relation  REOUIP.FMFNT 

domain  COMPANY,  numeric  9:  key 
domain  PROJECT,  string  10;  key 
domain  PAiPT,  string  10:  key 
domain  QnAiNTITY,  numeric  6 
end  REQUIREMENT 

relation  PRODUCT 

domain  COMPANY,  numeric  9:  key 
domain  PROJECT,  string  10;  key 
domain  PART,  string  10:  key 
domain  QUANTITY,  numeric  6 
end  PRODUCT 

relation  Ievt^'NTORY 

domain  COMPANY,  numeric  9;  key 
domain  PAP'^,  string  10:  key 
domain  QUANTITY,  numeric  6 
end  ■^^Tv^NTORY 

relation  C.ASH 

domain  COMPANY,  numeric  key 
domain  AMOUNT,  numeric  9 


end  CASH 
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end  PPODgAME 

The  OFFFF  relation  contains  all  current  offers  to  sail  goods. 
The  TPANSACT’TON  rela-t-ion  contains  a  history  of  all  transactions 
which  have  beer  made,  Records  of  when  and  which  projects  have 
been  completed  are  kept  in  the  COMPLETION  relation.  The 
PEQUTRFMENT  and  PRODUCT  relations  give  the  parts  required  and 
parts  produced  by  each  project.  The  INVENTORY  and  CASH  relations 
record  the  inventory  and  cash  positions  of  all  the  companies. 

Companies  are  identified  by  the  player's  APL  account  number. 
All  times  are  in  sixtieths  of  seconds  from  midnight  Fab,  29/March 
1  I960,  The  project  and  part  names  will  be  chosan  by  the  game 
supervisor. 


Ru  l^es 

1)  Each  player  starts  with  $2C,C00  cash  and  no  inventoc/. 

2)  Each  player  will  be  assigned  a  number  of  projects  to  be 
completed,  each  project  with  its  own  deadline.  Thara  will  be 
a  penalty  of  ?.^CC  per  day  or  part  of  a  day  by  which  th^^ 
deadline  is  missed.  A  project  may  not  be  completed  more  than 
once . 

3)  -A  player  may  complete  a  project  when  he  has  all  the  required 
supplies  in  his  inventory  and  not  committed  for  sale  (se^ 
rule  4).  A  projec*  is  comple-^ed  by: 

i)  Removina  the  required  supplies  from  the  company's 


inventory. 
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ii)  rntpring  th<?  produc^-.s  in  the  company's  inventory. 

iii)  Inserting  a  COMPLETION  tuple  giving  the  company  number, 
proiect  number  and  the  time  the  project  was  completed. 

goods  are  offered  for  sale  by  inserting  a  tuple  giving  the 
company  number,  product  number,  the  offered  price  per  unit 
and  the  quantity  available  in  the  OFFER  relation.  There  are 
the  followina  restrictions: 

i)  A  company  must  always  have  sufficient  inventor/  to  fill 
all  its  sales  offers, 

ii)  A  company  may  not  have  more  than  one  sales  offer  for  the 
same  part  and  price  at  the  same  tim«, 

5)  Goods  are  bought  by  accepting  a  sales  offer.  Each  purchase 
may  be  for  any  quantity  up  to  and  including  the  guantit/  on 
the  sales  offer.  '^he  price  per  unit  must  be  that  on  the 
purchas<=  offer  and  the  purchaser  must  have  sufficient  cash  to 
pay  for  the  goods.  The  procedure  for  making  a  purchase  is  as 
follows: 

i)  If  the  purchase  is  for  the  whole  quantity  of  the  offer 
then  the  OFFER  tuple  is  deleted.  Otherwise  the  quantity 
of  the  purchase  is  subtracted  from  the  quantity  on  the 
OFFER  tuple. 

ii)  The  total  purchase  pric^  is  removed  from  the  purchaser's 
cash  and  added  to  the  seller’s  cash. 

iii)  The  goods  purchased  are  removed  from  the  seller's 
inventory  and  added  to  the  purchaser's  in  V'l^n  tor  y . 
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iv)  A  tuple  giving  the  part  number,  quantity,  price  per 
unit,  purchaser  and  seller  numbers  and  the  time  of  the 
purchase  is  inserted  into  the  TPANSACTION  relation. 

6)  A  player  may  cancel  any  of  his  sales  offers  by  deleting  the 
OFFEE  tuple.  A  player  may  change  the  quantity  or  price  of 
any  of  his  offers  by  replacing  the  OFFER  tuple.  Any  such 
change  has  no  effect  on  any  purchases  previously  male  on  that 
offer. 

7)  A  player  may  not  change  or  cancel  another  player’s  sales 
offer,  cash  or  inventory  exce pt  to  ef f ect  a  purchase  as  set 
out  in  rule  5. 

8)  No  player  may  replace,  delete  or  insert  a  tuple  in  the 

EEQUIREMENT  or  PPOPUCT  relations. 

9)  No  player  may  replace  or  delete  a  tuple  in  the  THANSAETION 

relation. 

10)  The  obj=^ct  of  the  game  is  to  have  the  most  valuable  inventory 

at  the  end  of  the  game.  At  the  end  of  the  game  a  player’s 

assets  will  be  evaluated  according  to  the  following  rules: 

i)  Cash  is  valued  at  face  value. 

ii)  Goods  are  valued  using  a  weighted  average  of  the  prices 
paid  for  the  goods,  '^he  transactions  are  numbered 
consecu"*" i vely ,  in  the  order  in  which  the  transactions 
were  made,  with  the  first  transaction  given  the  number 
1.  If  qi  is  the  quantity  purchased  in  transaction  i 
•^hen  the  weight  for  transact- ion  i  is  i*qi.  If  pi  is  the 
price  per  unit  in  transaction  i,  T  =  sum  i=’'qi^pi  and  w  = 
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sum  i*ai,  where  in  both  sums  i  ranges  ever  the 
transactions  involving  part  X,  then  each  unit  of  part  X 
will  be  valued  at  '^/W, 

iii)  A  player  is  penalized  $1000  for  each  project  which  he 
has  not  completed. 

11)  The  penalty  for  violating  any  of  the  rules,  other  than  the 
missing  of  a  deadline,  is  $100  plus  any  gain  made  as  a  result 
of  the  violation.  Any  rule  violations  may  be  corrected  by 
the  game  administrator  during  the  game.  Penalties  will  be 
assessed  at  the  end  of  the  game. 
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Chapter  6 

Command  Syntax 

Hi§£lL2lll£3.i_§!lbs}rste  j_Command_Sin  tax 

<da^a  base  coinmand>  ::=  <retrieval  command> 

I  <modif icati on  command> 

\  <control  command> 


=  GU 

*<root  seg 

ment  na 

me> 

» 

<qua 

li f icat 

ion 

express 

ion>* 

1  GPU 

*  <root  seg 

ment  na 

me> 

« 

f 

<qua 

lif icat 

ion 

express 

ion>* 

1  GN 

•  {<segment 

name> 

{ ;  <q 

uali f is 

a  t  ion 

express 

ion>}  }  ’ 

1  GHN 

*  {<  seg  men 

t  name> 

{;< 

qualifi 

sat io  n 

express 

ion>}  )  ' 

I  GNP 

*  {<segmen 

t  name> 

{;< 

qiiali  f  i 

sa tien 

3xpress 

ion>}  }  ' 

1  GHNP 

*  {<segmen 

t  name> 

{;< 

qualif i 

s  a  t  i  a  n 

express 

ion>}  }  * 

<modif ication  command>  : ;=  REPLACE 

1  INSERT  ' <segment  narae>’ 
I  DELETE 

<control  cominand>  ::=  OPEN  '<data  bas'^  name>* 

j  CLOSE  ’<data  base  name>* 

1  RELEASE 
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<qua  li  f  icat  ion  pyprGssion>  <co[npoiind  condition> 

<coinpound  condition>  ::=  <simple  condition> 

\  <coinpound  condition>  <logical  c:anne3tor> 

<compound  conditiDn> 

I  (  <compound  condition>  ) 

<simplG  coiidition>  ::=  (  <field  name>  <conditional  operator> 

<valu3>  ) 

<loqical  connGctor>  ::=  ‘'.NP  1  OR 

<conditional  operator>  ::=<|<|=|^1>1> 

<valuG>  ::=  f  any  real  nuirher,  date  or  string] 

<data  base  na[ne>  :  [any  valid  FOBS  variable  up  to  10  oharaoters] 

<segmGnt  name>  [any  valid  EDBS  variable  up  to  20  characters] 

<field  name>  : [any  valid  EDBS  variable  up  to  20  characters] 

Hierarchical  Buffer  Commands 
{<Z'.PL  identifier>  <-}  READ  *  [<field  nanie>]  ' 

<value  or  ZiPL  identifier>  WRITE  *  <segfflent  name>' 


< value  or  APL  identifier>  ^<field  nameh* 
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S£ii.ii2Q.§.i_Sliksistem_Command__S_jrn  tax 


<data  base  coinmand> 


<retrieval  command> 
<modif ication  comraand> 
<control  command> 


<retrie7al  coinmand>  GFT  ’  ;  }  <target  List> 

{  ;  <guali f ication  expr ession>} ’ 
I  GETHOLD  *  f<lirait>  ;  }  <targ9t  list> 

{  ;  <qualif ication  9xpression>} * 


<rnodif ication  command> 


UPDATE 

PUT  *[<liinit>  ;  }  <relation  name>' 
DELETE  *<relation  name>  ;  <simple 

cond ition>* 


<control  com[nand>  ::=  OPEN  *<data  base  name>* 

1  CLOSE  *<data  base  name>' 

I  PEL  EASE 

<qua lif icat icn  expression>  ::=  <compoiind  condition> 


<con\ponnd  condition>  ::=  <siiriple  condition> 

]  <join  condition> 

I  <coinpound  conditionP  <logical  conne::tor> 
<compound  condicion> 

I  (  <compound  condition>  ) 


<siiiiple  condition>  ::=  (  <relation  name>  .  <domain  nams> 

<conditional  operator>  <valu3>  ) 


<join  condition> 


(  <relation  name> 


<domain  name> 


-100 


<relation  naine>  .  <(1oinairi  na!iie>  ) 

<targGt  list>  <rGaltior.  name>  {,<domain  name>) 

I  <target  lis t> , <relation  naine> 

{.<doinain  narae>} 

<logical  conrector>  ::=  A-ND  j  OP 

<conditional  opGrator>  ::=<  |<  1=1  *  \  >|  ^ 

::=  [any  positive  integer] 

<value>  ::=  [any  real  number,  date  or  string] 

<data  base  name>  : :=  [any  valid  EDBS  variable  up  to  10  oiaraoters] 
<relation  name>  [any  valid  PDFS  variable  up  to  20  c^xaracter3] 

<domain  name>  ::=  [any  valid  EDBS  variable  up  to  20  characters] 

Relational  Buf fer  , Commands 

{<APL  identifier>  4-}  READ  '  f<relation  na  [ne>.  <domain  aam2>} 

[;  <specif  ication>}  ’ 

<value  or  identifier>  WRITE  '  [<ralation  name>. 

<domain  naipe>}  [;  <speci f icat ion}  ’ 
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